[Bug 23451] VMWare Thinapps (packaged with version >4.5) don't run

wine-bugs at winehq.org wine-bugs at winehq.org
Thu Jul 1 15:27:29 CDT 2010


http://bugs.winehq.org/show_bug.cgi?id=23451


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |focht at gmx.net




--- Comment #2 from Anastasius Focht <focht at 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-support/

--- 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

-- 
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.


More information about the wine-bugs mailing list