http://bugs.winehq.org/show_bug.cgi?id=33236
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|source |obfuscation Status|UNCONFIRMED |NEW CC| |focht@gmx.net Component|-unknown |ntdll Summary|Bible Converter Project |Bible Converter Project |fails to convert anything |fails to convert anything | |(VMWare ThinApp 4.x, Wine's | |LdrLoadDll doesn't behave | |like native, needs to call | |NtXXXSection API) Ever Confirmed|0 |1
--- Comment #5 from Anastasius Focht focht@gmx.net 2013-03-17 18:00:21 CDT --- Hello folks,
the application starts a helper process "Simple_Bible_Reader_v2.3.exe" which is extracted from resource section of main executable.
--- snip --- 002b:Call KERNEL32.CreateProcessW(00000000,0032d858 L"C:\users\focht\Temp\tmp7ac4.tmp.exe BIB 0 "" 1 "" True "C:\users\focht\Temp\tmp7ac5.tmp.log"",00000000,00000000,00000000,00000400,00000000,00000000,0032cf00,0032cef0) ret=7e1c0cd3 ... 002f:Call KERNEL32.__wine_kernel_init() ret=7bc546d0 002f:trace:loaddll:load_native_dll Loaded L"C:\users\focht\Temp\tmp7ac4.tmp.exe" at 0x79bf0000: native 002b:Ret KERNEL32.CreateProcessW() retval=00000001 ret=7e1c0cd3 --- snip ---
tmp7ac4.tmp.exe -> Simple_Bible_Reader_v2.3.exe
Unfortunately "Simple_Bible_Reader_v2.3.exe" is wrapped with VMware ThinApp 4.x. (hence the source code of the main application is useless here).
--- snip --- Generic check : VMware ThinApp 4.0.x - 4.6.x - 2011 - Copyright 2006-2009 VMware, Inc. thinstal.com / www.vmware.com , Overlay : 090500... Nothing discovered ... ThinyApp Packager Suit - packed crypted --- snip ---
This application virtualization (sandboxing) solution hooks many native API. Reminds me of bug 23451 (which is about native API process creation sequence).
--- snip --- ... 002b:Call KERNEL32.GetModuleHandleW(79bf2282 L"nt0_dll.dll") ret=79bf21bc 002b:Ret KERNEL32.GetModuleHandleW() retval=00000000 ret=79bf21bc 002b:Call KERNEL32.SetFilePointer(0000003c,000ba186,0032ed6c,00000000) ret=79bf1f08 002b:Ret KERNEL32.SetFilePointer() retval=000ba186 ret=79bf1f08 002b:Call KERNEL32.ReadFile(0000003c,0032ed8c,0000000c,0032ed68,00000000) ret=79bf1f1a 002b:Ret KERNEL32.ReadFile() retval=00000001 ret=79bf1f1a 002b:Call KERNEL32.VirtualAlloc(00000000,00018185,00101000,00000040) ret=79bf171d 002b:Ret KERNEL32.VirtualAlloc() retval=7ffb0000 ret=79bf171d 002b:Call KERNEL32.SetFilePointer(0000003c,000ba192,0032ed68,00000000) ret=79bf1f08 002b:Ret KERNEL32.SetFilePointer() retval=000ba192 ret=79bf1f08 002b:Call KERNEL32.ReadFile(0000003c,7ffb0000,00018185,0032ed64,00000000) ret=79bf1f1a 002b:Ret KERNEL32.ReadFile() retval=00000001 ret=79bf1f1a 002b:Call ntdll.NtCreateSection(0032ed54,0000000e,00000000,0032ed5c,00000040,08000000,00000000) ret=79bf26c1 002b:Ret ntdll.NtCreateSection() retval=00000000 ret=79bf26c1 002b:Call ntdll.NtMapViewOfSection(00000040,ffffffff,0032ed70,00000001,00000000,00000000,0032ed58,00000002,00100000,00000040) ret=79bf2700 002b:Ret ntdll.NtMapViewOfSection() retval=00000000 ret=79bf2700 ... 002b:Call ntdll.LdrLoadDll(00000000,00000000,00354218,0032eb28) ret=003403c3 002b:Ret ntdll.LdrLoadDll() retval=c0000135 ret=003403c3 002b:Call ntdll.NtRaiseHardError(40000015,00000001,00000001,0032e31c,00000000,0032e310) ret=0033c895 002b:fixme:ntdll:NtRaiseHardError : stub. Errorstatus was 40000015 002b:Ret ntdll.NtRaiseHardError() retval=c0000002 ret=0033c895 002b:Call ntdll.NtTerminateProcess(ffffffff,c0000001) ret=0033c8bf --- snip ---
The problem here is that Wine's loader doesn't behave like native loader (some native APIs are not called during dll load sequence).
MSDN article that describes what native does: http://msdn.microsoft.com/en-us/magazine/cc301727.aspx ("What Goes On Inside Windows 2000: Solving the Mysteries of the Loader")
The virtualizer expects LdrLoadDll internal helpers to check and map the file through NtXXXSection() API (NtOpenSection with the fully qualified file name to check for existence, NtCreateSection + NtMapViewOfSection for loading etc.).
Wine's loader doesn't do this hence the hooked native API never get called, leading to failure.
Regards