April 2011 - Wine-Bugs - list.winehq.org

[Bug 10273] New: satisfy SafeDisc 2.x heuristic API analyzer by "adjusting" API exports/entry statistics of wine builtins
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=10273 Summary: satisfy SafeDisc 2.x heuristic API analyzer by "adjusting" API exports/entry statistics of wine builtins Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8924) --> (http://bugs.winehq.org/attachment.cgi?id=8924) Patch which should fix SafeDisc 2.x copy protection api analyzer issue Hello, if not interested in technical details goto (2) ;-) I made this a separate bug report like http://bugs.winehq.org/show_bug.cgi?id=9925 (SafeDisc 1.x stopper) because SafeDisc has many flavors that differ in various technical ways and can't be discussed/handled in a single SafeDisc "metabug" like http://bugs.winehq.org/show_bug.cgi?id=219 SafeDisc Major version based separation allows better tracking of "completion" state (1.x/2.x/3.x/4.x). ----------- (1) It took me a couple of days to get an idea what SafeDisc 2.x really does with the API exports and to find a way to cope with it... Various anti-debugging techniques and nasty runtime code obfuscation made this journey somewhat challenging. Parts of SafeDisc 2.x analyze the API code of the following system libraries: kernel32.dll (wine builtin) user32.dll (wine builtin) gdi32.dll (wine builtin) cdasdtst.dll (developer backdoor?) The latter one is probably a "developer backdoor", used to verify their code/algorithms (not needed to be present). For each of these libraries all named exports are taken into account. A number of API entry opcode sequences are read and used for statistical analysis (number depends on type of encountered opcodes). >From what I've seen there is some kind of "behavioural probability" of each API entry calculated, with typical opcode sequences having a "weighting". Just think of advanced heuristic detection methods of antivirus scanners and you get the idea ;-). Anyway, wine's builtin libraries differ in their signatures from windows entry code and to make things worse, wine's +relay/+snoop feature heavily interferes with the analyzer results. :-( First I made some experiments with additional (dummy) function exports, small __asm__ wrappers with opcode sequences to see how the distribution of opcodes influences the analyzer results. The result was rather disappointing. I needed a large number of exports to gain some results but not significantly enough to get below the "bad" threshold. Then I came across the magic "0" value. As soon as I used this value either as first .byte on API entry or init value for data export, the entry scan was short circuited. This value seemed to have the highest influence of all code/data sequences used. I added quite a number of data exports - aliased to initialized "0" value - safe enough to let even wine's +relay work (remember: relay code influences analyzer). If you look at the patch don't get mad ;-) You will see a crapload of named "__wine_safedisc2" data exports/aliases added to wine builtin kernel32, user32 and gdi32. For the record: http://bugs.winehq.org/show_bug.cgi?id=9926 which talks about "problematic" gdi32 data exports (pfnPalette stuff) in SafeDisc 3.x. SafeDisc 2.x code triggers SEH upon exported function pointers too but this is gracefully handled. No harm at all. I wonder if this is really a problem in SafeDisc 3.x ... I thought about other possible solutions but found no one easier to implement to prove my findings without hurting wine too much :-) Making wrappers of the whole kernel32, user32, gdi32 named exports API just to please the entry analyzer is not an option to me. Another way could be the relocation of export table upon module loading, expanding it at runtime by adding the required number of "statistics fakers" (data exports with zero init). This requires modifying the ntdll loader .. though i'm not sure if this approach breaks other applications/braindamaged PE protection stuff which expect certain conditions to be met (tables present at specific sections/memory areas). ------------------------------ (2) Well, take it as proof of concept. Play with it. I tested my patch with a few SafeDisc 2.x games I have original media. No cracks/no-cd patches were used. Only official game patches were used. Battlefield 1924 (1.6x) - SafeDisc 2.6/2.8 Road To Rome (BF1942 expansion) - SafeDisc 2.8 Battlefield Vietnam - SafeDisc 2.9 All of these work fine for me with the patch applied. Please test this patch on many SafeDisc 2.x games as possible and report your results (works or works not). Make sure you have original media mounted and drive/data is visible within wine. If it fails for first time, the media might not ready yet, try again then (I experienced this sometimes). Use this link to verify what SafeDisc Version is used: http://www.120search.net/ (alcohol software copy protection database) Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 48

[Bug 9798] New: bioshock demo needs glsl enabled
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=9798 Summary: bioshock demo needs glsl enabled Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8240) --> (http://bugs.winehq.org/attachment.cgi?id=8240) crash log with glsl disabled Hello, Bioshock demo crashes if glsl is not enabled. Attached are relevant traces made with: WINEDEBUG=+seh,+tid,+d3d,+d3d_shader wine ./Bioshock.exe -dx9 Using following registry settings enables bioshock demo to run: --- snip --- HKEY_CURRENT_USER/Software/Wine/Direct3D UseGLSL = "enabled" --- snip --- Optional: OffscreenRenderingMode = "fbo" ================== Addendum: wine --version wine-0.9.45-406-g2ba3247 Currently uses secuROM hack (http://bugs.winehq.org/attachment.cgi?id=8235 ) to run, see http://bugs.winehq.org/show_bug.cgi?id=7065 Be sure to include "-dx9" command line to work around directx 10 issue. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 10225] New: SafeDisc 2. x triggers async device ioctl status code propagation bug in wine server
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=10225 Summary: SafeDisc 2.x triggers async device ioctl status code propagation bug in wine server Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8843) --> (http://bugs.winehq.org/attachment.cgi?id=8843) relevant trace which shows ioctl status code propagation bug Hello, while testing my proof-of-concept patch which makes SafeDisc v2 (yuck!) finally work, I stumbled across a nasty ioctl status code propagation (completion) bug in wine server. Wasted several hours on it .. I was suspecting SD issue whole time, but its a wine server bug :( Attached is relevant trace (WINEDEBUG=+seh,+tid,+relay,+ntoskrnl,+server wine ./BfVietnam.exe) Before the bug is triggered, the SafeDisc security driver makes several device ioctl requests which return 0xC0000001 (unsuccessful) on purpose, e.g. reading debug Drx registers with index that does not exist. This is intended to fool reversers :-) The next operation - checking IDT entries should succeed - but does not (as seen from calling client). The kernel driver completes the operation successfully and returns irp.IoStatus.u.Status == 0 with xxxx bytes in output buffer. I verified it several times by debugging the kernel driver. Upon driver ioctl call return, get_next_device_request() is triggered again in ntoskrnl event loop which sets the return data (and status code) -> set_ioctl_result(). This queues an APC, waking up the client (alertable state). The client process device ioctl completes with 0 (FALSE) which is wrong. Further debugging showed that ioctl_completion APC (dlls/ntdll/file.c) returns the errornous status code in get_ioctl_result() when woken up by server. This error is then propagated in server_ioctl_file() to result in wrong NtDeviceIoControlFile() return code. What puzzled me is that "ioctl->status" is correctly set by set_ioctl_result() (=0) but get_ioctl_result() - called within client context - yields the previous error code (0xC0000001 of failed request). This is either a problem of global vs. thread local error status (global_error vs. current->error/thread) or the ioctl call data is the wrong one. The following patch works for me, letting SD 2.x continue - though i'm not sure if it's right: --- snip --- diff --git a/server/device.c b/server/device.c index 46b2796..8fe8f7c 100644 --- a/server/device.c +++ b/server/device.c @@ -528,7 +528,7 @@ DECL_HANDLER(get_ioctl_result) ioctl->out_data = NULL; } } - set_error( ioctl->status ); + list_remove( &ioctl->dev_entry ); release_object( ioctl ); /* no longer on the device queue */ } --- snip --- Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 8

[Bug 10293] New: sequentially running games/ apps with different SafeDisc versions fails
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=10293 Summary: sequentially running games/apps with different SafeDisc versions fails Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-kernel AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=8945) --> (http://bugs.winehq.org/attachment.cgi?id=8945) Patch which fixes various isses regarding kmode driver unload/reload Hello, currently wine's kernel mode driver cleanup/unloading facility has several issues when it comes to applications/games that unload and reload different driver versions on the fly. Example: run multiple SafeDisc 2.x, 3.x and 4.x games sequentially. Symptoms: game either hangs/crashes/exits silently Usually the SD security driver is placed in "c:\windows\system32\drivers\secdrv.sys" If a SafeDisc protected program encounters a driver version that is incompatible it does the following: - stop the current security service (should unload the driver) - unpack own security driver from resources to temp storage and move the binary to "c:\windows\system32\drivers\secdrv.sys", overwriting the previous - restart the service (loads the new driver) This currently fails for various reasons: (1) The driver binary is loaded using LoadLibrary() -> the matching FreeLibrary() is missing on service stop. This leads to sharing violation when the driver binary going to be replaced (CopyFile fails). (2) No driver unload routine called. Very problematic. Various objects (symlinks) created by driver entry are not freed. When the driver is reloaded the init routine usually fails with "object exists". (3) Driver state objects (driver_obj, driver_extension) have undefined state due to static storage. Raises all sorts of problems because the driver entry routine does not init all fields. --------- Attached is a patch which fixes these problems, allowing to sequentially run programs with different SafeDisc Versions. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 10

[Bug 10451] New: Various AutoDesk 2008 product installers fail due to unimplemented msi. MsiEnumComponentCostsW
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=10451 Summary: Various AutoDesk 2008 product installers fail due to unimplemented msi.MsiEnumComponentCostsW Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=9156) --> (http://bugs.winehq.org/attachment.cgi?id=9156) stub impl of msi.MsiEnumComponentCostsW to keep AutoDesk 2008 installers happy Hello, various AutoDesk 2008 product installers fail due to unimplemented msi.MsiEnumComponentCostsW API (mentioned in bug 9809). --- snip --- wine: Call from 0x7b841460 to unimplemented function msi.dll.MsiEnumComponentCostsW, aborting wine: Unimplemented function msi.dll.MsiEnumComponentCostsW called at address 0x7b841460 (thread 000e), starting debugger... Unhandled exception: unimplemented function msi.dll.MsiEnumComponentCostsW called in 32-bit code (0x7b8414d8). --- snip --- Attached patch makes installer happy. Though that API (A/W) should be fleshed out some day ... this is left as exercise for msi maintainers :-) If you test this on AutoDesk 2008 installers, you need my shell32/shlfileop patch from bug 9809 too. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 10478] New: wine server get/set thread context doesn' t work correctly if simultaneously used by debugger and debuggee
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=10478 Summary: wine server get/set thread context doesn't work correctly if simultaneously used by debugger and debuggee Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-debug AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=9209) --> (http://bugs.winehq.org/attachment.cgi?id=9209) WINEDEBUG=+tid,+server,+win trace of debugging session Hello, while debugging a target with some debugger I experienced severe problems with wine server get/set thread context implementation. It doesn't work correctly if the get/set thread context API is simultaneously used by both, the debugger and the debuggee to manage exception events/control execution transfer. Attached is WINEDEBUG=+tid,+seh,+win trace (don't bother with +win channel output, was for my own purpose). pid=0008, tid=0009 debugger main thread pid=0008, tid=000d debugger debug event loop thread pid=000e, tid=000f debuggee main thread pid=000e, tid=0010 debuggee child thread pid=000e, tid=0011 debuggee child thread pid=000e, tid=0012 debuggee child thread Search for "000d: get_thread_context() = ACCESS_DENIED { self=0, context={} }" in attached log and walk your way back... --- snip --- 000f: queue_exception_event( first=1, record={context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=00004000,esi=00004000,edi=00197430,ebp=0034e5d4,eip=7b841378,esp=0034e570,eflags=00200216,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=a3f67070,dr1=0012e150,dr2=0034eec0,dr3=00000000,dr6=00000006,dr7=00000200,float={00000003,0034e234,33746e49,00000032,00000000,000000f8,0034e280,0034e268,00087510,00198af0,00110014,00000001,00000318,00000000,4d430002,4d430000,00198e18,00000010,00000000,00000000,00000000,4d430003,00000000,00000000,00000000,00000000,00000000,00000000}},rec={code=e06d7363,flags=1,rec=(nil),addr=0x7b841300,params={19930520,34e670,79f9acc4}} ) 000d: *wakeup* signaled=0 cookie=0x616e24c0 0010: *sent signal* signal=10 0011: *sent signal* signal=10 0012: *sent signal* signal=10 000f: queue_exception_event() = 0 { handle=0x244 } --- snip --- Debuggee main thread throws first chance C++ exception (queues event). Ok. --- snip --- 0010: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000001f,ecx=613516a4,edx=00000008,esi=613516a4,edi=7ffd4000,ebp=613516b8,eip=600007f0,esp=61351670,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff4000,ffffffff,604b434d,035f0073,0034dc34,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffe,00000000,40038000,00004000}} ) 0010: set_thread_context() = 0 { self=1 } 0011: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=00000023,ecx=614624a0,edx=00000008,esi=614624a0,edi=7ffd0000,ebp=614624b4,eip=600007f0,esp=6146246c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0100,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffd,80000000,40078662,00000100}} ) 0011: set_thread_context() = 0 { self=1 } 0012: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000003a,ecx=6c101d70,edx=00000008,esi=6c101d70,edi=7ffcc000,ebp=6c101d84,eip=600007f0,esp=6c101d3c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0120,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,00000000,00000000,80000000,00003ffd,60000000,400785bc,00000120}} ) 0012: set_thread_context() = 0 { self=1 } --- snip --- The debuggee child threads get SIGUSR1, suspend themselves (on purpose!). Ok. --- snip --- 000d: wait_debug_event( get_handle=1 ) 000d: wait_debug_event() = 0 { pid=000e, tid=000f, wait=(nil), event={exception,{code=e06d7363,flags=1,rec=(nil),addr=0x7b841300,params={19930520,34e670,79f9acc4},first=1} } .. 000d: continue_debug_event( pid=000e, tid=000f, status=-2147418111 ) 000f: *wakeup* signaled=0 cookie=0x34dfd4 0010: *wakeup* signaled=258 cookie=0x7ffd77b4 0011: *wakeup* signaled=258 cookie=0x7ffd37b4 000d: continue_debug_event() = 0 .. --- snip --- Debugger wakes up and sees first chance C++ exception, decides to pass it to debuggee (resumes execution of threads). Ok. --- snip --- 000f: get_exception_status( handle=0x244 ) 000f: get_exception_status() = 80010001 { context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=00004000,esi=00004000,edi=00197430,ebp=0034e5d4,eip=7b841378,esp=0034e570,eflags=00200216,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=a3f67070,dr1=0012e150,dr2=0034eec0,dr3=00000000,dr6=00000006,dr7=00000200,float={00000003,0034e234,33746e49,00000032,00000000,000000f8,0034e280,0034e268,00087510,00198af0,00110014,00000001,00000318,00000000,4d430002,4d430000,00198e18,00000010,00000000,00000000,00000000,4d430003,00000000,00000000,00000000,00000000,00000000,00000000}} } 0010: get_thread_context( handle=0xfffffffe, flags=00010007, suspend=1 ) 0010: get_thread_context() = 0 { self=1, context={flags=0001001f,eax=00000003,ebx=0000001f,ecx=613516a4,edx=00000008,esi=613516a4,edi=7ffd4000,ebp=613516b8,eip=600007f0,esp=61351670,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff4000,ffffffff,604b434d,035f0073,0034dc34,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffe,00000000,40038000,00004000}} } 0011: get_thread_context( handle=0xfffffffe, flags=00010007, suspend=1 ) 0011: get_thread_context() = 0 { self=1, context={flags=0001001f,eax=00000003,ebx=00000023,ecx=614624a0,edx=00000008,esi=614624a0,edi=7ffd0000,ebp=614624b4,eip=600007f0,esp=6146246c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0100,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffd,80000000,40078662,00000100}} } 000d: select( flags=4, cookie=0x616e24c0, signal=(nil), prev_apc=(nil), timeout=+1.0000000, result={}, handles={0xa8} ) 000d: select() = PENDING { apc_handle=(nil), timeout=1c828ffa61af642 (+1.0000000), call={APC_NONE} } 0012: get_thread_context( handle=0xfffffffe, flags=00010007, suspend=1 ) 0012: get_thread_context() = 0 { self=1, context={flags=0001001f,eax=00000003,ebx=0000003a,ecx=6c101d70,edx=00000008,esi=6c101d70,edi=7ffcc000,ebp=6c101d84,eip=600007f0,esp=6c101d3c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0120,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,00000000,00000000,80000000,00003ffd,60000000,400785bc,00000120}} } 000f: get_process_info( handle=0xffffffff ) 000f: get_process_info() = 0 { pid=000e, ppid=0008, exit_code=259, priority=2, affinity=1, peb=0x7ffdf000, start_time=1c828ff9f2037c6 (-10.7374150), end_time=0 } 000f: queue_exception_event( first=1, record={context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=0034ee58,esi=0034ee58,edi=e0434f4d,ebp=0034ee20,eip=7b841378,esp=0034edbc,eflags=00200212,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=02d410d8,dr2=a3f67060,dr3=00000000,dr6=00110000,dr7=00000002,float={0034eaa4,00001302,00198d10,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001,0034eadc,79e783ca,00110000,00000000,79e783e6,a3f67cf4,00000001,00197430,00000000,00000008,00000000,0034eb14,7a3296dc,ffffffff,79e783e6,79e7839d,00110000}},rec={code=e0434f4d,flags=1,rec=(nil),addr=0x7b841300,params={80004002}} ) --- snip --- Main debuggee thread SEH evaluates first chance exception and converts it internally to CLR exception, throwing again. --- snip --- 0010: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000001f,ecx=613516a4,edx=00000008,esi=613516a4,edi=7ffd4000,ebp=613516b8,eip=600007f0,esp=61351670,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff4000,ffffffff,604b434d,035f0073,0034dc34,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffe,00000000,40038000,00004000}} ) 0010: set_thread_context() = 0 { self=1 } 0011: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=00000023,ecx=614624a0,edx=00000008,esi=614624a0,edi=7ffd0000,ebp=614624b4,eip=600007f0,esp=6146246c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0100,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,3ffe8000,00000000,80000000,00003ffd,80000000,40078662,00000100}} ) 0011: set_thread_context() = 0 { self=1 } 0012: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context={flags=0001001f,eax=00000003,ebx=0000003a,ecx=6c101d70,edx=00000008,esi=6c101d70,edi=7ffcc000,ebp=6c101d84,eip=600007f0,esp=6c101d3c,eflags=00200293,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={ffff037f,ffff0120,ffffffff,79e7a66b,06d90073,00000000,0000007b,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,3fff8000,00000000,80000000,00003ffe,00000000,00000000,00000000,80000000,00003ffd,60000000,400785bc,00000120}} ) 0012: set_thread_context() = 0 { self=1 } --- snip --- The debuggee child threads get SIGUSR1, suspend themselves again (on purpose!). Ok. --- snip --- 000d: suspend_thread( handle=0xd4 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xd8 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xf8 ) 000d: suspend_thread() = 0 { count=0 } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000f: *signal* signal=19 000d: get_thread_context() = 0 { self=0, context={flags=0001003f,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=0034ee58,esi=0034ee58,edi=e0434f4d,ebp=0034ee20,eip=7b841378,esp=0034edbc,eflags=00200212,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1=00000000,dr2=00000000,dr3=00000000,dr6=00000000,dr7=00000000,float={0034eaa4,00001302,00198d10,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001,0034eadc,79e783ca,00110000,00000000,79e783e6,a3f67cf4,00000001,00197430,00000000,00000008,00000000,0034eb14,7a3296dc,ffffffff,79e783e6,79e7839d,00110000}} } 000d: read_process_memory( handle=0xb8, addr=0x7b841378 ) 000f: *signal* signal=19 000d: read_process_memory() = 0 { data={8b} } 000d: resume_thread( handle=0xbc ) 000d: resume_thread() = 0 { count=1 } 000d: resume_thread( handle=0xd4 ) 000d: resume_thread() = 0 { count=1 } 000d: resume_thread( handle=0xd8 ) 000d: resume_thread() = 0 { count=1 } 000d: resume_thread( handle=0xf8 ) 000d: resume_thread() = 0 { count=1 } 000d: continue_debug_event( pid=000e, tid=000f, status=-2147418111 ) 000f: *wakeup* signaled=0 cookie=0x34e824 0010: *wakeup* signaled=258 cookie=0x7ffd77b4 0011: *wakeup* signaled=258 cookie=0x7ffd37b4 0012: *wakeup* signaled=258 cookie=0x7ffcf7b4 000d: continue_debug_event() = 0 --- snip --- Debugger wakes up again, now seeing the CLR exception. Debugger suspends debuggee threads - although unnecessary due to debugging event before = already suspended. This exception type is unhandled, main debuggee thread receives SIGSTOP. Execution of debuggee threads resumed. --- snip --- 000f: get_exception_status( handle=0x244 ) 000f: get_exception_status() = 80010001 { context={flags=00010007,eax=7b82c455,ebx=7b8ad1e4,ecx=00000000,edx=0034ee58,esi=0034ee58,edi=e0434f4d,ebp=0034ee20,eip=7b841378,esp=0034edbc,eflags=00200212,cs=0073,ds=007b,es=007b,fs=0033,gs=003b,dr0=00000000,dr1= .. 000f: *killed* exit_code=0 --- snip --- Debuggee main thread dies. Ok. --- snip --- 000d: wait_debug_event( get_handle=1 ) 000d: wait_debug_event() = 0 { pid=000e, tid=000f, wait=(nil), event={exit_thread,code=0} } 000d: suspend_thread( handle=0xd4 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xd8 ) 000d: suspend_thread() = 0 { count=0 } 000d: suspend_thread( handle=0xf8 ) 000d: suspend_thread() = 0 { count=0 } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: get_thread_context( handle=0xbc, flags=0001003f, suspend=0 ) 000d: get_thread_context() = ACCESS_DENIED { self=0, context={} } 000d: read_process_memory( handle=0xb8, addr=(nil) ) 000d: read_process_memory() = ACCESS_DENIED { data={} } .. --- snip --- Debugger wakes up, sees debuggee (main) thread termination event. Suspends remaining debuggee threads - although unnecessary due to debugging event before = already suspended. Now the problem: the debugger can't get the thread context of any debuggee threads nor process memory anymore after this point. Basically dead end here... The reason is the way server/thread.c/get_thread_context() and server/thread.c/set_thread_context() handles thread->context and thread->suspend_context data ("self" vs. "foreign" threads) child threads "self": set_thread_context() -> suspend == 1 -> thread->suspend_context filled get_thread_context(): req->suspend == 1 && thread == current && thread->suspend_context --- snip --- if (thread->context == thread->suspend_context) thread->context = NULL; set_reply_data_ptr( thread->suspend_context, sizeof(CONTEXT) ); thread->suspend_context = NULL; --- snip --- Which resets the context and suspend context data. Next time when the debugger itself tries to query the thread context of already suspended debuggee child threads it will obviously fail: "foreign" debugger thread: get_thread_context() -> suspend == 0 --- snip --- else if (thread != current && !thread->context) { /* thread is not suspended, retry (if it's still running) */ if (thread->state != RUNNING) set_error( STATUS_ACCESS_DENIED ); else set_error( STATUS_PENDING ); } --- snip --- I guess this is an oversight, a behavior not really intended? Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 11789] New: Recent Fls API additions break many installers/apps
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=11789 Summary: Recent Fls API additions break many installers/apps Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, after upgrading to recent GIT (wine-0.9.56-264-g848383a) it seems the recent Fls API additions broke almost every installer i'm working on ;-( http://source.winehq.org/git/wine.git/?a=commit;h=6d6e9a42b13c827d1cc795c3b… http://source.winehq.org/git/wine.git/?a=commit;h=b2ad268a8b7d7ac65029bbdd7… I won't question if there was a specific need to introduce this ... Reason of crash in FlsAlloc() is simple. Different TEB definition in <thread.h> vs. <winternl.h> leads to incorrect TEB allocation size (ntdll -> thread.h) vs. usage (fiber/Fls -> winternl.h) Solution: use winternl.h TEB definition to ensure correct TEB allocation size in dlls/ntdll/thread.c Either change include order of both (needs <stdarg.h>) .. or sync both .. or better get rid of the thread.h one to avoid such recurring problem. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4

[Bug 14499] New: ImageDirectoryEntryToDataEx: section header param [out, optional], needs to be zeroed before RtlImageRvaToVa
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=14499 Summary: ImageDirectoryEntryToDataEx: section header param [out, optional], needs to be zeroed before RtlImageRvaToVa Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dbghelp AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, a quickie, as title says. Section header param passed to ImageDirectoryEntryToDataEx is [out, optional]. Crashes RtlImageRvaToVa if caller doesn't initialize the out param to zero (stack var). --- snip --- .. 0020:Call dbghelp.ImageDirectoryEntryToDataEx(00340000,00000000,00000006,0032cc34,0032cc38) ret=004048ec 0020:Call ntdll.RtlImageNtHeader(00340000) ret=6076ce7b 0020:Ret ntdll.RtlImageNtHeader() retval=003400e8 ret=6076ce7b 0020:Call ntdll.RtlImageRvaToVa(003400e8,00340000,00001270,0032cc38) ret=6076ceeb 0020:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7bc4337a --- snip --- Fix: unconditionally "if (section) *section = NULL" on ImageDirectoryEntryToDataEx entry (like size). Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4

[Bug 14539] New: RtlIsTextUnicode regression: ideographic space should not be used in check for reversed control chars
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=14539 Summary: RtlIsTextUnicode regression: ideographic space should not be used in check for reversed control chars Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, a regression in RtlIsTextUnicode causes VS.NET 2005 Installer and probably others to fail. The setup database, a unicode .ini file is not correctly identified as such. --- snip --- 0026:Call setupapi.SetupOpenInfFileW(007eb3e8 L"E:\\vs\\setup\\setup.sdb",00000000,00000002,0033eab4) ret=5022237f 0026:Call KERNEL32.GetFullPathNameW(007eb3e8 L"E:\\vs\\setup\\setup.sdb",00000000,00000000,00000000) ret=606148a8 0026:Ret KERNEL32.GetFullPathNameW() retval=00000016 ret=606148a8 0026:Call ntdll.RtlAllocateHeap(00110000,00000000,0000002c) ret=606148e0 0026:Ret ntdll.RtlAllocateHeap() retval=00142a08 ret=606148e0 0026:Call KERNEL32.GetFullPathNameW(007eb3e8 L"E:\\vs\\setup\\setup.sdb",00000016,00142a08,00000000) ret=60614909 0026:Ret KERNEL32.GetFullPathNameW() retval=00000015 ret=60614909 0026:Call KERNEL32.CreateFileW(00142a08 L"E:\\vs\\setup\\setup.sdb",80000000,00000001,00000000,00000003,00000000,00000000) ret=60614947 0026:Ret KERNEL32.CreateFileW() retval=00000068 ret=60614947 0026:Call KERNEL32.GetFileSize(00000068,00000000) ret=60614966 0026:Ret KERNEL32.GetFileSize() retval=00012f9e ret=60614966 0026:Call KERNEL32.CreateFileMappingW(00000068,00000000,00000002,00000000,00012f9e,00000000) ret=6061499b 0026:Ret KERNEL32.CreateFileMappingW() retval=0000006c ret=6061499b 0026:Call KERNEL32.MapViewOfFile(0000006c,00000004,00000000,00000000,00012f9e) ret=60614a2f 0026:Ret KERNEL32.MapViewOfFile() retval=003b0000 ret=60614a2f 0026:Call ntdll.NtClose(0000006c) ret=60614a3d 0026:Ret ntdll.NtClose() retval=00000000 ret=60614a3d 0026:Call ntdll.RtlAllocateHeap(00110000,00000008,0000002c) ret=60614a80 0026:Ret ntdll.RtlAllocateHeap() retval=00142a40 ret=60614a80 0026:Call ntdll.RtlAllocateHeap(00110000,00000000,00025f3c) ret=60614ab3 0026:Ret ntdll.RtlAllocateHeap() retval=00147ab8 ret=60614ab3 0026:Call ntdll.RtlIsTextUnicode(003b0000,00012f9e,00000000) ret=60614ae8 0026:Ret ntdll.RtlIsTextUnicode() retval=00000000 ret=60614ae8 0026:Call ntdll.RtlAllocateHeap(00110000,00000000,00025f3c) ret=60614b2b 0026:Ret ntdll.RtlAllocateHeap() retval=0016da00 ret=60614b2b 0026:Call KERNEL32.MultiByteToWideChar(00000000,00000000,003b0000 "\xff\xfe\r",00012f9e,0016da00,00012f9e) ret=60614b6f 0026:Ret KERNEL32.MultiByteToWideChar() retval=00012f9e ret=60614b6f 0026:Call ntdll.RtlReAllocateHeap(00110000,00000010,00147ab8,00000000) ret=606145d9 0026:Ret ntdll.RtlReAllocateHeap() retval=00147ab8 ret=606145d9 0026:Call ntdll.RtlFreeHeap(00110000,00000000,0016da00) ret=60614ba9 0026:Ret ntdll.RtlFreeHeap() retval=00000001 ret=60614ba9 0026:Call KERNEL32.UnmapViewOfFile(003b0000) ret=60614bc2 0026:Ret KERNEL32.UnmapViewOfFile() retval=00000001 ret=60614bc2 0026:Call ntdll.RtlFreeHeap(00110000,00000000,00142a40) ret=60614be5 0026:Ret ntdll.RtlFreeHeap() retval=00000001 ret=60614be5 0026:Call KERNEL32.CloseHandle(00000068) ret=606149af 0026:Ret KERNEL32.CloseHandle() retval=00000001 ret=606149af 0026:Call ntdll.RtlFreeHeap(00110000,00000000,00142a08) ret=606149d2 0026:Ret ntdll.RtlFreeHeap() retval=00000001 ret=606149d2 0026:Ret setupapi.SetupOpenInfFileW() retval=ffffffff ret=5022237f .. 0026:Call KERNEL32.WritePrivateProfileStringW(501b82fc L"Error",0033ed28 L"Error1",007ebbe8 L"0:0:setup.exe:LoadSetupDatabase() : The .sdb file is either missing, corrupt, or the signiture portion is missing",0033eb14 L"C:\\windows\\temp\\msinterr.txt") ret=501fcdeb --- snip --- The input data for your pleasure: --- snip --- $ hexdump -n 256 -C setup.sdb 00000000 ff fe 0d 00 0a 00 5b 00 56 00 65 00 72 00 73 00 |......[.V.e.r.s.| 00000010 69 00 6f 00 6e 00 5d 00 0d 00 0a 00 53 00 69 00 |i.o.n.].....S.i.| 00000020 67 00 6e 00 61 00 74 00 75 00 72 00 65 00 20 00 |g.n.a.t.u.r.e. .| 00000030 3d 00 20 00 22 00 24 00 57 00 69 00 6e 00 64 00 |=. .".$.W.i.n.d.| 00000040 6f 00 77 00 73 00 20 00 4e 00 54 00 24 00 22 00 |o.w.s. .N.T.$.".| 00000050 0d 00 0a 00 50 00 72 00 6f 00 76 00 69 00 64 00 |....P.r.o.v.i.d.| 00000060 65 00 72 00 3d 00 22 00 4d 00 69 00 63 00 72 00 |e.r.=.".M.i.c.r.| 00000070 6f 00 73 00 6f 00 66 00 74 00 20 00 56 00 69 00 |o.s.o.f.t. .V.i.| 00000080 73 00 75 00 61 00 6c 00 20 00 53 00 74 00 75 00 |s.u.a.l. .S.t.u.| 00000090 64 00 69 00 6f 00 20 00 32 00 30 00 30 00 35 00 |d.i.o. .2.0.0.5.| 000000a0 20 00 50 00 72 00 6f 00 66 00 65 00 73 00 73 00 | .P.r.o.f.e.s.s.| 000000b0 69 00 6f 00 6e 00 61 00 6c 00 20 00 45 00 64 00 |i.o.n.a.l. .E.d.| 000000c0 69 00 74 00 69 00 6f 00 6e 00 20 00 2d 00 20 00 |i.t.i.o.n. .-. .| 000000d0 45 00 4e 00 55 00 22 00 0d 00 0a 00 56 00 65 00 |E.N.U.".....V.e.| 000000e0 72 00 73 00 69 00 6f 00 6e 00 3d 00 38 00 30 00 |r.s.i.o.n.=.8.0.| 000000f0 30 00 2e 00 31 00 30 00 30 00 2e 00 30 00 30 00 |0...1.0.0...0.0.| --- snip --- BOM for UTF-16 is there. The problem is the ideographic space (U+3000) in reverse control chars check (punctuation symbol or whitespace in languages like Chinese, Japanese, or Korean). --- snip --- static const WCHAR byterev_control_chars[] = {0x0d00,0x0a00,0x0900,0x2000,0x0030,0}; --- snip --- This clashes with the multibyte mapping of digit 0: 0x30 -> 0x0030 By removing the reversed ideographic space, the file is correctly recognized. Problematic commit: 8f3ae2011c39d092b0c8e2e6a9aabddbd2596748 Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 14568] New: Silence FIXME from CoGetContextToken stub to prevent flooding of trace output when COM+ context is queried from .NET runtime
by wine-bugs＠winehq.org Oct. 12, 2011

Oct. 12, 2011

http://bugs.winehq.org/show_bug.cgi?id=14568 Summary: Silence FIXME from CoGetContextToken stub to prevent flooding of trace output when COM+ context is queried from .NET runtime Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ole32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, ole32.CoGetContextToken being currently a stub prints out large amounts of FIXME's when .NET runtime queries COM+ context for run/debugged .NET applications. --- snip --- .. fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub fixme:ole:CoGetContextToken stub .. <repeat this gazillion times> --- snip --- Please use a static or remove the FIXME. It's really annoying and makes console tracing/debugging of .NET apps really messy. And no, WINEDEBUG=-ole is *not* an option, it actually hides other bugs. Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4