http://bugs.winehq.org/show_bug.cgi?id=23451
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #2 from Anastasius Focht focht@gmx.net 2010-07-01 15:27:28 --- Hello,
this problem won't be fixed easily. It requires a redesign of Wine's process creation code.
The logs won't give much information, one has to debug some brain damaged virtualization layer. Basically it fails to properly create the child process "sandboxed one" - the way it wants.
--- snip --- "[*** PostMapExecutableBaseIntoChild failed C0000141]" ""C:\Program Files\Notepad++\notepad++.exe"" "RelaunchUsingCreateProcess::CreateProcess failed" --- snip ---
The 0xC0000141 status is custom made within virtualization layer it has nothing to do with some failed (native) API call.
When VMWare Thinapp layer creates the (real) child process, it creates it initially suspended. That reminded me of a technique used in malware to completely replace the executable image before code is being run in child address space. Basically the original image is unmapped using NtUnmapViewOfSection() and virtual memory is allocated in target address space, big enough to hold new (replacement) PE image. The new image is copied into target space (from in memory resources or disk) and then PEB members and entry point address get patched to new values (using thread context of main thread).
But this seems not the case here. CreateProcessW() returns successfully and the thinapp wrapper looks at internal data structures only to find out something didn't go right. When I skimmed through wrapper process address space, I came to an interesting memory block, near the end of user vm:
--- snip --- Wine-dbg>info maps ... 7f000000 7ffaffff free 7ffb0000 7ffbffff commit private RWX 7ffc0000 7ffcbfff free 7ffcc000 7ffcffff commit private RW 7ffd0000 7ffd3fff commit private RW 7ffd4000 7ffd7fff commit private RW 7ffd8000 7ffdbfff commit private RW 7ffdc000 7ffdefff free 7ffdf000 7ffdffff commit private RW 7ffe0000 7ffeffff commit private RW
Wine-dbg>x/100x 0x7ffb0000 0x7ffb0000: 3a9e4068 a3e06868 81e9003e 68804384 0x7ffb0010: 683a8980 3ea3e068 8472e900 60688043 0x7ffb0020: 68683d6f 003a7d10 438463e9 8d806880 0x7ffb0030: 5068683d e9003a7f 80438454 c1f1d868 0x7ffb0040: 5cb0687b 95e90034 68804384 7bc20c7c 0x7ffb0050: 345cb068 8486e900 00008043 00000000 0x7ffb0060: 00000000 00000000 00000000 00000000 0x7ffb0070: 00000000 00000000 00000000 00000000 0x7ffb0080: 00000000 00000000 00000000 00000000 --- snip ---
Suspicious as I am, I disassembled it:
--- snip --- Wine-dbg>disas 0x7ffb0000 0x7ffb0000: pushl $0x683a9e40 0x7ffb0005: pushl $0x3ea3e0 0x7ffb000a: jmp 0x003e8490 0x7ffb000f: pushl $0x683a8980 0x7ffb0014: pushl $0x3ea3e0 0x7ffb0019: jmp 0x003e8490 0x7ffb001e: pushl $0x683d6f60 0x7ffb0023: pushl $0x3a7d10 0x7ffb0028: jmp 0x003e8490 0x7ffb002d: pushl $0x683d8d80 0x7ffb0032: pushl $0x3a7f50 0x7ffb0037: jmp 0x003e8490 0x7ffb003c: pushl $0x7bc1f1d8 0x7ffb0041: pushl $0x345cb0 0x7ffb0046: jmp 0x003e84e0 0x7ffb004b: pushl $0x7bc20c7c 0x7ffb0050: pushl $0x345cb0 0x7ffb0055: jmp 0x003e84e0 0x7ffb005a: addb %al,0x0(%eax) 0x7ffb005c: addb %al,0x0(%eax) --- snip ---
That pretty much looks like trampoline code from hooks. Resolving the addresses revealed the following:
--- snip --- 0x683a9e40 MessageBoxA 0x683a8980 MessageBoxW 0x683d6f60 ShowWindow 0x683d8d80 ShowWindowAsync 0x7bc1f1d8 __wine_stub_NtCreateProcess in ntdll: nop 0x7bc20c7c __wine_stub_ZwCreateProcess in ntdll: nop --- snip ---
Digging deeper into jump target code for NtCreateProcess() hook it seems the virtualization layer partly replaces the params on its own (section object!) before calling the real OS entry. Though it would be pointless here because Wine doesn't even provide proper stubs for these native API.
What is most likely missing is a proper NT-like process creation sequence, resulting in calls to native APIs (for section creation, along with other stuff), with a final one to NtCreateProcess(). Because Wine doesn't resemble Windows' process creation, calls to native API (ought to be hooked) are never made. Hence some steps are simply "left out" leading to failure.
I'll leave it to Alexandre to decide if Wine will take the route of being more native API call sequence compatible one day. I currently see no value in redesigning process creation code just to please some brain damaged userland virtualization layers like ThinApp and Xenocode.
---
Ironically I came along this blog:
http://www.vreference.com/2010/03/18/thinapp-4-5-best-new-feature-linux-supp...
--- quote --- I try pack some trivial application with ThinApp 4.5 but on Ubuntu Linux with last version of wine don’t work any ThinApp applications. Every have problem with error “Crash in RelaunchUsingCreateProcess” On windows all work fine. --- quote ---
Obviously the problem I analyzed above.
The best part:
--- quote --- I don’t doubt there are still issues. I just appreciate the direction they are going in and the collaborative support they are giving to the WINE community. Hopefully they can make this work in most cases. --- quote ---
Sure sure ... I wonder how much do people get paid to spread stuff like this? Or is it drugs? ;-)
Regards