https://bugs.winehq.org/show_bug.cgi?id=43615
Bug ID: 43615 Summary: 32Bit Process Hacker 2.39.124 crashes in 64Bit prefix Product: Wine Version: 2.15 Hardware: x86 URL: http://processhacker.sourceforge.net/downloads.php OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: dark.shadow4@web.de Distribution: ---
Created attachment 59034 --> https://bugs.winehq.org/attachment.cgi?id=59034 Log
32Bit program works in 32Bit prefix, 64Bit program works in 64Bit prefix. But 32Bit program crashes in 64Bit prefix.
https://bugs.winehq.org/show_bug.cgi?id=43615
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, win64
https://bugs.winehq.org/show_bug.cgi?id=43615
--- Comment #1 from Gijs Vermeulen gijsvrm@gmail.com --- This works fine for me in wine-3.17, can you retest?
I downloaded the binaries and moved the x86 folder to Program Files (x86) and ran ProcessHacker.exe. It shows an error/warning that you are running the 32bit version on a 64bit OS, but the program starts fine.
https://bugs.winehq.org/show_bug.cgi?id=43615
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED URL|http://processhacker.source |https://github.com/processh |forge.net/downloads.php |acker/processhacker/release | |s/download/v2.39/processhac | |ker-2.39-bin.zip Component|-unknown |advapi32 Fixed by SHA1| |445996d31ba5818eb9fe4e41130 | |349b6730284a1 Summary|32Bit Process Hacker |32-bit Process Hacker |2.39.124 crashes in 64Bit |2.39.124 crashes in 64-bit |prefix |WINEPREFIX | |(advapi32.EnumServicesStatu | |sEx returns garbage on | |Wow64) Hardware|x86 |x86-64 Resolution|--- |FIXED CC| |focht@gmx.net
--- Comment #2 from Anastasius Focht focht@gmx.net --- Hello folks,
this was fixed some time ago by commit https://source.winehq.org/git/wine.git/commitdiff/445996d31ba5818eb9fe4e4113...
Thanks Hans
https://www.winehq.org/pipermail/wine-patches/2017-November/thread.html#1662...
Reminder: Always try to report with vanilla Wine first, only use Wine-Staging when you want to demonstrate a bug/regression in Wine-Staging.
Trace with old vanilla Wine 2.15
--- snip --- $ WINEDEBUG=+tid,+seh,+relay,+ntdll wine ./ProcessHacker.exe >>log.txt 2>&1 ... 0032:Call advapi32.OpenSCManagerW(00000000,00000000,00000005) ret=00476e5c ... 0032:Ret advapi32.OpenSCManagerW() retval=001d7038 ret=00476e5c 0032:Call ntdll.RtlAllocateHeap(00570000,00000004,00008000) ret=0049f658 0032:Ret ntdll.RtlAllocateHeap() retval=00652120 ret=0049f658 0032:Call advapi32.EnumServicesStatusExW(001d7038,00000000,0000003b,00000003,00652120,00008000,00d2e79c,00d2e78c,00000000,00000000) ret=0049f677 ... 0032:Ret advapi32.EnumServicesStatusExW() retval=00000001 ret=0049f677 0032:Call ntdll.RtlAllocateHeap(00570000,00000004,000003d4) ret=00476ed8 0032:Ret ntdll.RtlAllocateHeap() retval=0065a128 ret=00476ed8 0032:Call ntdll.RtlUpcaseUnicodeChar(00000042) ret=00476f4d 0032:Ret ntdll.RtlUpcaseUnicodeChar() retval=00000042 ret=00476f4d 0032:Call ntdll.RtlUpcaseUnicodeChar(00000049) ret=00476f4d 0032:Ret ntdll.RtlUpcaseUnicodeChar() retval=00000049 ret=00476f4d 0032:Call ntdll.RtlUpcaseUnicodeChar(00000054) ret=00476f4d 0032:Ret ntdll.RtlUpcaseUnicodeChar() retval=00000054 ret=00476f4d 0032:Call ntdll.RtlUpcaseUnicodeChar(00000053) ret=00476f4d 0032:Ret ntdll.RtlUpcaseUnicodeChar() retval=00000053 ret=00476f4d 0032:Call ntdll.RtlUpcaseUnicodeChar(000024d8) ret=00476f4d 0032:Ret ntdll.RtlUpcaseUnicodeChar() retval=000024be ret=00476f4d 0032:Call ntdll.RtlUpcaseUnicodeChar(00000065) ret=00476f4d 0032:Ret ntdll.RtlUpcaseUnicodeChar() retval=00000045 ret=00476f4d 0032:Call ntdll.RtlUpcaseUnicodeChar(000024d8) ret=00476f4d 0032:Ret ntdll.RtlUpcaseUnicodeChar() retval=000024be ret=00476f4d 0032:Call ntdll.RtlUpcaseUnicodeChar(00000065) ret=00476f4d 0032:Ret ntdll.RtlUpcaseUnicodeChar() retval=00000045 ret=00476f4d 0032:trace:seh:raise_exception code=c0000005 flags=0 addr=0x490ad4 ip=00490ad4 tid=0032 0032:trace:seh:raise_exception info[0]=00000000 0032:trace:seh:raise_exception info[1]=ffffffff 0032:trace:seh:raise_exception eax=0065a164 ebx=006521a4 ecx=00000001 edx=00652121 esi=00652121 edi=00000000 0032:trace:seh:raise_exception ebp=00d2e79c esp=00d2e790 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210202 0032:trace:seh:call_stack_handlers calling handler at 0x7bca1a60 code=c0000005 flags=0 0032:Call KERNEL32.UnhandledExceptionFilter(00d2e2f8) ret=7bca1a89 0032:trace:seh:start_debugger Starting debugger "winedbg --auto 8 248" --- snip ---
The first four 'ntdll.RtlUpcaseUnicodeChar()' after 'advapi32.EnumServicesStatusExW()': 0x42,0x49,0x54,0x54 -> 'BITS' service name The fifth, 'RtlUpcaseUnicodeChar(000024d8)' already contains garbage.
That already gave some hints. Combining trace log and live debugging I found the most probable location in the sources:
https://github.com/processhacker/processhacker/blob/v2.39/ProcessHacker/srvp...
--- snip --- VOID PhServiceProviderUpdate( _In_ PVOID Object ) { static SC_HANDLE scManagerHandle = NULL; static ULONG runCount = 0;
static PPH_HASH_ENTRY nameHashSet[256]; static PPHP_SERVICE_NAME_ENTRY nameEntries = NULL; static ULONG nameEntriesCount; static ULONG nameEntriesAllocated = 0;
LPENUM_SERVICE_STATUS_PROCESS services; ULONG numberOfServices; ULONG i; PPH_HASH_ENTRY hashEntry; ... if (!scManagerHandle) { scManagerHandle = OpenSCManager(NULL, NULL, SC_MANAGER_CONNECT | SC_MANAGER_ENUMERATE_SERVICE);
if (!scManagerHandle) return; }
services = PhEnumServices(scManagerHandle, 0, 0, &numberOfServices);
if (!services) return;
// Build a hash set containing the service names.
// This has caused a massive decrease in background CPU usage, and // is certainly much better than the quadratic-time string comparisons // we were doing before (in the "Look for dead services" section).
nameEntriesCount = 0;
if (nameEntriesAllocated < numberOfServices) { nameEntriesAllocated = numberOfServices + 32;
if (nameEntries) PhFree(nameEntries); nameEntries = PhAllocate(sizeof(PHP_SERVICE_NAME_ENTRY) * nameEntriesAllocated); }
PhInitializeHashSet(nameHashSet, PH_HASH_SET_SIZE(nameHashSet));
for (i = 0; i < numberOfServices; i++) { PPHP_SERVICE_NAME_ENTRY entry;
entry = &nameEntries[nameEntriesCount++]; PhInitializeStringRefLongHint(&entry->Name, services[i].lpServiceName); entry->ServiceEntry = &services[i]; PhAddEntryHashSet( nameHashSet, PH_HASH_SET_SIZE(nameHashSet), &entry->HashEntry, PhpHashServiceNameEntry(entry) ); } ... --- snip ---
Final proof: I've cherry-picked 445996d31ba5818eb9fe4e41130349b6730284a1 on top of Wine 2.15 (with small manual conflict resolution) and the crash went away.
--- snip --- $ git tag -r --contains 445996d31ba5818eb9fe4e41130349b6730284a1 | sort -V | head -1 wine-2.21 --- snip ---
https://www.winehq.org/announce/2.21
$ sha1sum processhacker-2.39-bin.zip 8e8f8423d163d922242b8b7d85427664f77edc97 processhacker-2.39-bin.zip
$ du -sh processhacker-2.39-bin.zip 3.3M processhacker-2.39-bin.zip
$ wine --version wine-3.17-95-g726abdb388
Regards
https://bugs.winehq.org/show_bug.cgi?id=43615
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #3 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.18.
-
wine-bugs＠winehq.org