January 2012 - Wine-Devel - list.winehq.org

Re: Profiing windows apps

by Ralph Little

Hi Stefan, I did put together a test for this and DirectX does indeed return DDERR_INVALIDPARMS. Here is a snippet that encapsulates what I tried: ======================== IDirectDraw * pDD = NULL; IDirectDrawSurface * pDDSPrimary = NULL; DDSURFACEDESC ddsd; ...<initialisation etc>... memset(&ddsd, 0, sizeof(ddsd)); ddsd.dwSize = sizeof(ddsd); ddsd.dwFlags = DDSD_CAPS | DDSD_PIXELFORMAT | DDSD_HEIGHT | DDSD_WIDTH; ddsd.ddsCaps.dwCaps = DDSCAPS_SYSTEMMEMORY | DDSCAPS_ZBUFFER; ddsd.dwHeight = 600; ddsd.dwWidth = 800; ddsd.ddpfPixelFormat.dwSize = sizeof(DDPIXELFORMAT); hr = pDD->CreateSurface(&ddsd, &pDDSPrimary, NULL); ======================== DirectX returns DDERR_INVALIDPARAMS from CreateSurface. I have tried to recreate as much a possible the graphical situation as it would be in The Sims at this point. Fullscreen, with 800x600 video mode. I assume that if the caller specifies DDSCAPS_ZBUFFER, the you must also specify some PIXEL format information. DDSD_PIXELFORMAT is present, but there are no format flags. I have to admit that I am a bit of a novice when it comes to DirectX so any guidance here would be helpful. I see that the lpSurface is NULL, which I thought was an error. However, I see that this is optional if the caller wishes the system to manage the surface memory. Any error returned by this function the Sims at this point to causes it to crash. Therefore, it seems to me that if it succeeds in Windows, it must have passed something different. If only we could see the source :D Cheers, Ralph >________________________________ > From: Stefan Dösinger <stefandoesinger(a)gmx.at> >To: wine-devel(a)winehq.org; Ralph Little <littlesincanada(a)yahoo.co.uk> >Sent: Tuesday, January 31, 2012 12:08:51 PM >Subject: Re: Profiing windows apps > >Am Dienstag, 31. Januar 2012, 17:29:23 schrieb Ralph Little: >> Hi, >> I'm looking at bug #9672 again in the The Sims. >> The app crashes early on during initialisation in DirectDraw. The problem >> occurs after CreateSurface returns an error, since it would appear that the >> DDSURFACEDESC passed into the call is foobar. This would lead me to >> conclude that something on the lead up to that call is precipitating that >> rogue call. >From looking at the bug report(ddsurfacedesc.ddpfPixelFormat.dwFlags = 0) I >think it's worth writing a test to see how Windows responds to the >CreateSurface call before spending too much time debugging this. It is quite >possible that Windows creates the surface just fine. > > >

Jan. 31, 2012

Re: Profiing windows apps

by Stefan Dösinger

Am Dienstag, 31. Januar 2012, 17:29:23 schrieb Ralph Little: > Hi, > I'm looking at bug #9672 again in the The Sims. > The app crashes early on during initialisation in DirectDraw. The problem > occurs after CreateSurface returns an error, since it would appear that the > DDSURFACEDESC passed into the call is foobar. This would lead me to > conclude that something on the lead up to that call is precipitating that > rogue call. >From looking at the bug report(ddsurfacedesc.ddpfPixelFormat.dwFlags = 0) I think it's worth writing a test to see how Windows responds to the CreateSurface call before spending too much time debugging this. It is quite possible that Windows creates the surface just fine.

Jan. 31, 2012

Re: quartz: If the MediaSeeking is not implemented all the way up the passthru chain fall back to the filtergraph's clock to find position.

by Aric Stewart

ahh ok, i see what the problem is. Thanks -aric On 1/31/12 1:45 PM, Alexandre Julliard wrote: > Aric Stewart<aric(a)codeweavers.com> writes: > >> Resolves bug Bug 25606 >> --- >> dlls/quartz/filtergraph.c | 6 +++++- >> 1 files changed, 5 insertions(+), 1 deletions(-) > > It doesn't work: > > ../../../tools/runtest -q -P wine -M quartz.dll -T ../../.. -p quartz_test.exe.so filtergraph.c&& touch filtergraph.ok > wine: Unhandled page fault on read access to 0x00000000 at address 0x690fff17 (thread 0066), starting debugger... > Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x690fff17). > Register dump: > CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b > EIP:690fff17 ESP:0032fc70 EBP:0032fcd8 EFLAGS:00010246( R- -- I Z- -P- ) > EAX:00000000 EBX:69195fa4 ECX:0032fcb8 EDX:0012cc0c > ESI:0032fd28 EDI:0012c878 > Stack dump: > 0x0032fc70: 0032fd28 69195fa4 0032fcd8 690fb648 > 0x0032fc80: 0012c878 0000000d 00000000 00000000 > 0x0032fc90: 0032fd34 0032fd3c 00000000 6877a314 > 0x0032fca0: 6877418e 0012c7c0 80004001 6877a314 > 0x0032fcb0: 6877418e 0032fd28 00000000 00000000 > 0x0032fcc0: 00000001 6877428a 690fb58b 6877a314 > Backtrace: > =>0 0x690fff17 MediaSeeking_GetCurrentPosition+0x137(iface=0x12c7c8, pCurrent=0x32fd28) [/home/julliard/wine/wine/dlls/quartz/filtergraph.c:2460] in quartz (0x0032fcd8) > 1 0x6876ddea func_filtergraph+0x3a9() [/home/julliard/wine/wine/dlls/quartz/tests/filtergraph.c:284] in quartz_test (0x0032fd58) > 2 0x68767392 main+0x3a1(argc=0, argv=(nil)) [/home/julliard/wine/wine/dlls/quartz/tests/../../../include/wine/test.h:556] in quartz_test (0x0032fe28) > 3 0x68773865 __wine_spec_exe_entry+0x74(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in quartz_test (0x0032fe70) > 4 0x6848cc4c call_process_entry+0xb() in kernel32 (0x0032fe88) > 5 0x6848ddcf start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1083] in kernel32 (0x0032fec8) > 6 0x6837a0b0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) > 7 0x6837cd9d call_thread_func+0x7c(entry=0x6848dd70, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2532] in ntdll (0x0032ffa8) > 8 0x6837a08e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) > 9 0x6835219e start_process+0x1d(kernel_start=0x6848dd70) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) > 10 0x68028a9d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) > 0x690fff17 MediaSeeking_GetCurrentPosition+0x137 [/home/julliard/wine/wine/dlls/quartz/filtergraph.c:2460] in quartz: movl 0x0(%eax),%edx > 2460 IReferenceClock_GetTime(This->refClock,&time); > >

Jan. 31, 2012

Re: quartz: If the MediaSeeking is not implemented all the way up the passthru chain fall back to the filtergraph's clock to find position.

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > Resolves bug Bug 25606 > --- > dlls/quartz/filtergraph.c | 6 +++++- > 1 files changed, 5 insertions(+), 1 deletions(-) It doesn't work: ../../../tools/runtest -q -P wine -M quartz.dll -T ../../.. -p quartz_test.exe.so filtergraph.c && touch filtergraph.ok wine: Unhandled page fault on read access to 0x00000000 at address 0x690fff17 (thread 0066), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x690fff17). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:690fff17 ESP:0032fc70 EBP:0032fcd8 EFLAGS:00010246( R- -- I Z- -P- ) EAX:00000000 EBX:69195fa4 ECX:0032fcb8 EDX:0012cc0c ESI:0032fd28 EDI:0012c878 Stack dump: 0x0032fc70: 0032fd28 69195fa4 0032fcd8 690fb648 0x0032fc80: 0012c878 0000000d 00000000 00000000 0x0032fc90: 0032fd34 0032fd3c 00000000 6877a314 0x0032fca0: 6877418e 0012c7c0 80004001 6877a314 0x0032fcb0: 6877418e 0032fd28 00000000 00000000 0x0032fcc0: 00000001 6877428a 690fb58b 6877a314 Backtrace: =>0 0x690fff17 MediaSeeking_GetCurrentPosition+0x137(iface=0x12c7c8, pCurrent=0x32fd28) [/home/julliard/wine/wine/dlls/quartz/filtergraph.c:2460] in quartz (0x0032fcd8) 1 0x6876ddea func_filtergraph+0x3a9() [/home/julliard/wine/wine/dlls/quartz/tests/filtergraph.c:284] in quartz_test (0x0032fd58) 2 0x68767392 main+0x3a1(argc=0, argv=(nil)) [/home/julliard/wine/wine/dlls/quartz/tests/../../../include/wine/test.h:556] in quartz_test (0x0032fe28) 3 0x68773865 __wine_spec_exe_entry+0x74(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in quartz_test (0x0032fe70) 4 0x6848cc4c call_process_entry+0xb() in kernel32 (0x0032fe88) 5 0x6848ddcf start_process+0x5e(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/kernel32/process.c:1083] in kernel32 (0x0032fec8) 6 0x6837a0b0 call_thread_func_wrapper+0xb() in ntdll (0x0032fed8) 7 0x6837cd9d call_thread_func+0x7c(entry=0x6848dd70, arg=0x7ffdf000, frame=0x32ffc8) [/home/julliard/wine/wine/dlls/ntdll/signal_i386.c:2532] in ntdll (0x0032ffa8) 8 0x6837a08e call_thread_entry_point+0x11() in ntdll (0x0032ffc8) 9 0x6835219e start_process+0x1d(kernel_start=0x6848dd70) [/home/julliard/wine/wine/dlls/ntdll/loader.c:2612] in ntdll (0x0032ffe8) 10 0x68028a9d wine_call_on_stack+0x1c() in libwine.so.1 (0x00000000) 0x690fff17 MediaSeeking_GetCurrentPosition+0x137 [/home/julliard/wine/wine/dlls/quartz/filtergraph.c:2460] in quartz: movl 0x0(%eax),%edx 2460 IReferenceClock_GetTime(This->refClock, &time); -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2012

Re: Profiing windows apps

by Dmitry Timoshkov

Ralph Little <littlesincanada(a)yahoo.co.uk> wrote: > Does anyone have any experience with tracing apps in real Windows in the context of Wine development? > > Should I use a profiler or is there a simpler method? Try logger.exe from Debugging Tools For Windows. -- Dmitry.

Jan. 31, 2012

Re: crypt32: Only accept trailing NULLs in a certificate common name.

by Juan Lang

> Wow, I clearly didn't read that you moved the code over to > match_common_name. Apparently I'm not quite conscious today, my > apologies! Clearly I wasn't quite conscious when I reviewed your patch in the first place :) No worries, for security fixes lots of checking is always worthwhile! --Juan

Jan. 31, 2012

Re: crypt32: Only accept trailing NULLs in a certificate common name.

by Erich E. Hoover

On Tue, Jan 31, 2012 at 11:10 AM, Juan Lang <juan.lang(a)gmail.com> wrote: > ... > Well, sort of. The byte-by-byte comparison takes place component by > component. The boundary between each component is defined by the > presence of a '.'. That's why, in my example, I have an embedded NULL > immediately prior to a '.'. After the end of each component is found, > it's passed to match_domain_component. In the current git version, > each component strips a NULL, hence an embedded NULL is accepted. In > the version I sent, only trailing NULL(s) are removed. > ... Wow, I clearly didn't read that you moved the code over to match_common_name. Apparently I'm not quite conscious today, my apologies! Erich Hoover ehoover(a)mines.edu

Jan. 31, 2012

Re: crypt32: Only accept trailing NULLs in a certificate common name.

by Juan Lang

Hi Erich, On Tue, Jan 31, 2012 at 9:34 AM, Erich E. Hoover <ehoover(a)mines.edu> wrote: > On Tue, Jan 31, 2012 at 10:23 AM, Erich E. Hoover <ehoover(a)mines.edu> wrote: >> On Tue, Jan 31, 2012 at 10:04 AM, Juan Lang <juan.lang(a)gmail.com> wrote: >>> Sorry I didn't spot this earlier. Without this, someone who registers >>> a certificate common name with an embedded NULL, like >>> "codeweavers.com\0.badguy", could fool crypt32 into accepting it for a >>> domain it isn't registered to, codeweavers.com in my example. >> >> It looks like you've just changed it to allow more than one NULL at >> the end... It seems to me that the matching code already handles the >> case of an embedded NULL, since it goes through the allowed_len >> characters and manually checks each byte (rather than using a routine >> like strcmp() which stops at NULLs). Well, sort of. The byte-by-byte comparison takes place component by component. The boundary between each component is defined by the presence of a '.'. That's why, in my example, I have an embedded NULL immediately prior to a '.'. After the end of each component is found, it's passed to match_domain_component. In the current git version, each component strips a NULL, hence an embedded NULL is accepted. In the version I sent, only trailing NULL(s) are removed. You're right that I allow multiple trailing NULLs rather than just one, but that difference seems immaterial. The key one is to prevent NULLs immediately prior to dots. --Juan

Jan. 31, 2012

Re: crypt32: Only accept trailing NULLs in a certificate common name.

by Erich E. Hoover

On Tue, Jan 31, 2012 at 10:23 AM, Erich E. Hoover <ehoover(a)mines.edu> wrote: > On Tue, Jan 31, 2012 at 10:04 AM, Juan Lang <juan.lang(a)gmail.com> wrote: >> Sorry I didn't spot this earlier. Without this, someone who registers >> a certificate common name with an embedded NULL, like >> "codeweavers.com\0.badguy", could fool crypt32 into accepting it for a >> domain it isn't registered to, codeweavers.com in my example. > > It looks like you've just changed it to allow more than one NULL at > the end... It seems to me that the matching code already handles the > case of an embedded NULL, since it goes through the allowed_len > characters and manually checks each byte (rather than using a routine > like strcmp() which stops at NULLs). Please forgive the "Reply to all" fail. Erich Hoover ehoover(a)mines.edu

Jan. 31, 2012

Profiing windows apps

by Ralph Little

Hi, I'm looking at bug #9672 again in the The Sims. The app crashes early on during initialisation in DirectDraw. The problem occurs after CreateSurface returns an error, since it would appear that the DDSURFACEDESC passed into the call is foobar. This would lead me to conclude that something on the lead up to that call is precipitating that rogue call. I have a legal Windows XP and I wish to trace the calls leading up to this point with real Windows/DirectX to compare with what is happening to Wine so that I can assess what is upsetting the application, since I can't see anything in the Wine trace prior to that that looks suspicious. Does anyone have any experience with tracing apps in real Windows in the context of Wine development? Should I use a profiler or is there a simpler method? Cheers, Ralph

Jan. 31, 2012