January 2021 - Wine-bugs - list.winehq.org

[Bug 37062] New: Wireshark 1.10 'dumpcap.exe' tool crashes on unimplemented function wpcap.dll.pcap_findalldevs
by wine-bugs＠winehq.org 18 Mar '21

18 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=37062 Bug ID: 37062 Summary: Wireshark 1.10 'dumpcap.exe' tool crashes on unimplemented function wpcap.dll.pcap_findalldevs Product: Wine Version: 1.7.23 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, as the summary says ... --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Wireshark $ wine ./dumpcap.exe ... wine: Call from 0x7b83ae8f to unimplemented function wpcap.dll.pcap_findalldevs, aborting wine: Unimplemented function wpcap.dll.pcap_findalldevs called at address 0x7b83ae8f (thread 0026), starting debugger... --- snip --- $ sha1sum Wireshark-win32-1.10.10rc0-7-gce4abdf.exe 94b6c2d2029dd00aa05b25bfc4fc6bbdc4ec405d Wireshark-win32-1.10.10rc0-7-gce4abdf.exe $ du -sh Wireshark-win32-1.10.10rc0-7-gce4abdf.exe 22M Wireshark-win32-1.10.10rc0-7-gce4abdf.exe $ wine --version wine-1.7.23-90-gbdeb761 Regards -- 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.

2 5

[Bug 37094] New: Wireshark 1.10 'dumpcap.exe' tool crashes on unimplemented function wpcap.dll.pcap_open_live
by wine-bugs＠winehq.org 18 Mar '21

18 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=37094 Bug ID: 37094 Summary: Wireshark 1.10 'dumpcap.exe' tool crashes on unimplemented function wpcap.dll.pcap_open_live Product: Wine Version: 1.7.24 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Hello folks, continuation of bug 37062 --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Wireshark $ wine ./dumpcap.exe ... Capturing on 'virbr0' wine: Call from 0x7b83ae8f to unimplemented function wpcap.dll.pcap_open_live, aborting wine: Unimplemented function wpcap.dll.pcap_open_live called at address 0x7b83ae8f (thread 0009), starting debugger... --- snip --- $ sha1sum Wireshark-win32-1.10.10rc0-7-gce4abdf.exe 94b6c2d2029dd00aa05b25bfc4fc6bbdc4ec405d Wireshark-win32-1.10.10rc0-7-gce4abdf.exe $ du -sh Wireshark-win32-1.10.10rc0-7-gce4abdf.exe 22M Wireshark-win32-1.10.10rc0-7-gce4abdf.exe $ wine --version wine-1.7.24-14-gd1749b5 Regards -- 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.

2 5

[Bug 12099] New: .NET Framework 1.1 installer requires loadperf. dll in case of AeDebug -> Auto=0 (unhandled exception dialog)
by wine-bugs＠winehq.org 18 Mar '21

18 Mar '21

http://bugs.winehq.org/show_bug.cgi?id=12099 Summary: .NET Framework 1.1 installer requires loadperf.dll in case of AeDebug -> Auto=0 (unhandled exception dialog) Product: Wine Version: CVS/GIT Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Created an attachment (id=11486) --> (http://bugs.winehq.org/attachment.cgi?id=11486) example patch to add loadperf.dll and simple UnloadPerfCounterTextStringsW stub preventing .NET 1.1 installer exception Hello, VS.NET 7.x installers modify AeDebug which results in error message box from .NET Framework 1.1 installer due to an unhandled exception. With default AeDebug Auto=1 and standalone .NET 1.1 installation you won't notice it because this exception doesn't affect overall "success" result of installer. You can capture output from console to see winedbg actually spawned. VS.NET 7.x installers add/modify the following JIT debugging keys: --- snip --- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger Auto: 1 -> 0 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger Default: cordbg.exe !a 0x%x8 --- snip --- Extract from .msi file: --- snip --- _FldbVs7eve_RegFile_887_00017.3643236F_FC70_11D3_A536_0090278A1BB8 2 SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug Auto 0 _VS_Debugging___VS7JIT_____X86.3643236F_FC70_11D3_A536_0090278A1BB8) .. --- snip --- You can simulate the behaviour on clean ~/.wine if you manually set AeDebug/Auto=0 (default is 1) and then execute the standalone .NET 1.1 installer. --- snip --- 002d:Call KERNEL32.lstrlenA(0034f55c "2008-03-17 21:20:25\t\tStarting\tUninstalling performance counters\r\n") ret=79e88b92 .. 002d:Call KERNEL32.LoadLibraryA(79e61310 "loadperf.dll") ret=79e907ed 002d:Ret KERNEL32.LoadLibraryA() retval=00000000 ret=79e907ed 002d:Call KERNEL32.GetLastError() ret=79e907f9 002d:Ret KERNEL32.GetLastError() retval=0000007e ret=79e907f9 002d:Call KERNEL32.RaiseException(c06d007e,00000000,00000001,0034f960) ret=79e9082c 002d:trace:seh:raise_exception code=c06d007e flags=0 addr=0x7b8419a0 002d:trace:seh:raise_exception info[0]=0034f910 002d:trace:seh:raise_exception eax=7b82c3e9 ebx=7b8af3e4 ecx=00000000 edx=0034f904 esi=0034f904 edi=0034f880 002d:trace:seh:raise_exception ebp=0034f868 esp=0034f804 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00200212 002d:trace:seh:call_stack_handlers calling handler at 0x402518 code=c06d007e flags=0 .. 002d:Call KERNEL32.UnhandledExceptionFilter(0034f350) ret=7c34c456 wine: Unhandled exception 0xc06d007e at address 0x7b8419a0 (thread 002d), starting debugger... 002d:Call user32.MessageBoxA(00000000,0034efd8 "Unhandled exception 0xc06d007e at address 0x7b8419a0.\nDo you wish to debug it?",7b8a3e47 "Exception raised",00000014) ret=7b841deb --- snip --- The message box is shown with the option to dismiss the exception or to debug it. This can be pretty confusing to users who have no knowledge how to deal with this. Well, actually this exception should never occur. Wine can prevent this problem by providing a simple loadperf.dll and UnloadPerfCounterTextStringsW stub. Output after patch: --- snip --- 0041:Ret KERNEL32.LoadLibraryA() retval=607d0000 ret=79e907ed 0041:Call KERNEL32.InterlockedExchange(79e96fa8,607d0000) ret=79e9083e 0041:Ret KERNEL32.InterlockedExchange() retval=00000000 ret=79e9083e 0041:Call KERNEL32.GetProcAddress(607d0000,79e919b4 "UnloadPerfCounterTextStringsW") ret=79e908c4 0041:Ret KERNEL32.GetProcAddress() retval=607d8808 ret=79e908c4 0041:Call loadperf.UnloadPerfCounterTextStringsW(0034f9d0 L"u \"ASP.NET_1.1.4322\"",00000001) ret=79e86e64 0041:fixme:loadperf:UnloadPerfCounterTextStringsW (L"u \"ASP.NET_1.1.4322\"", 1): stub! 0041:Ret loadperf.UnloadPerfCounterTextStringsW() retval=00000000 ret=79e86e64 --- snip --- Please add this dll and the UnloadPerfCounterTextStringsW stub. The attached patch is provided as example to quickly validate the problem solution. 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.

2 13

[Bug 44704] New: Screenhero installer runs into crash window ( Access Violation)
by wine-bugs＠winehq.org 18 Mar '21

18 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=44704 Bug ID: 44704 Summary: Screenhero installer runs into crash window (Access Violation) Product: Wine Version: 3.3 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: --- The Screenhero installer runs into a crash window (Access Violation) while calling FormatMessageW with id 0x800b0109 which apparently is CERT_E_UNTRUSTEDROOT I don`t know where this error comes from but with the patch it gets further to install all files***, though there`s still a crash in the end. Patch is at: https://bugs.winehq.org/attachment.cgi?id=60704&action=diff ***: It also suffers from bug 34989, so you need workaround from here to avoid a hang: https://bugs.winehq.org/attachment.cgi?id=60702&action=diff -- 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.

2 5

[Bug 45841] New: Battleye' s BEDaisy.sys requires that PsThreadType and PsProcessType are defined
by wine-bugs＠winehq.org 18 Mar '21

18 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=45841 Bug ID: 45841 Summary: Battleye's BEDaisy.sys requires that PsThreadType and PsProcessType are defined Product: Wine Version: 3.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: dereklesho52(a)Gmail.com Distribution: --- Without these two structures, battleye's BEDaisy.sys will crash on an EXCEPTION_ACCESS_VIOLATION. Alongside the fixes for #45664 and #44912, Battleye will launch the game. I will commit my fix to my github shortly after posting this bug: https://github.com/Guy1524/wine/commits/battleye-work-stable -- 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.

2 7

[Bug 44911] New: BattlEye 'BEDaisy' kernel service crashes on unimplemented function ntoskrnl.exe.PsGetProcessId
by wine-bugs＠winehq.org 18 Mar '21

18 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=44911 Bug ID: 44911 Summary: BattlEye 'BEDaisy' kernel service crashes on unimplemented function ntoskrnl.exe.PsGetProcessId Product: Wine Version: 3.5 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, continuation of bug 44910 --- snip --- $ WINEDEBUG=+seh,+relay,+ntoskrnl wine net start BEDaisy >>log.txt 2>&1 ... 0034:Call driver init 0x78d000 (obj=0x11cc28,str=L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\BEDaisy") ... 0034:Ret ntdll.NtQuerySystemInformation() retval=00000000 ret=7bc803ab 0034:Ret ntoskrnl.exe.ZwQuerySystemInformation() retval=00000000 ret=0082d9b5 ... 0034:Call KERNEL32.RaiseException(80000100,00000001,00000002,0065eb78) ret=7ec1ace2 ... 0034:trace:seh:raise_exception code=80000100 flags=1 addr=0x7b446c33 ip=7b446c33 tid=0034 0034:trace:seh:raise_exception info[0]=7ec1ad00 0034:trace:seh:raise_exception info[1]=7ec1e697 wine: Call from 0x7b446c33 to unimplemented function ntoskrnl.exe.PsGetProcessId, aborting wine: Unimplemented function ntoskrnl.exe.PsGetProcessId called at address 0xf7c30023:0x7b446c33 (thread 0034), starting debugger... --- snip --- $ sha1sum Tibia_Setup.exe 50951008ccc402cc32407bfc56a88da873e3e9bd Tibia_Setup.exe $ du -sh Tibia_Setup.exe 5.2M Tibia_Setup.exe $ wine --version wine-3.5-107-gf4573adb0f Regards -- 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.

2 6

[Bug 44912] New: Tibia client reports 'Failed to launch game', needs ' ntdll.RtlCreateUserProcess' implementation
by wine-bugs＠winehq.org 18 Mar '21

18 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=44912 Bug ID: 44912 Summary: Tibia client reports 'Failed to launch game', needs 'ntdll.RtlCreateUserProcess' implementation Product: Wine Version: 3.5 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, besides the traditional 'KERNEL32.CreateProcessW()' API it also uses native API to create process(es). --- snip --- $ pwd /home/focht/winetest/drive_c/users/focht/Local Settings/Application Data/Tibia/packages/Tibia/bin $ WINEDEBUG=+seh,+relay,+ntoskrnl,+ntdll wine ./client.exe >>log.txt 2>&1 ... 003d:Call KERNEL32.CreateProcessW(00000000,001c8630 L"\"C:\\users\\focht\\Local Settings\\Application Data\\Tibia\\packages\\Tibia\\bin\\client_launcher.exe\" ",00000000,00000000,00000000,00000410,00000000,01d7c6b8 L"C:/users/focht/Local Settings/Application Data/Tibia/packages/Tibia/bin",0033cf2c,0033cf1c) ret=0047235f ... 0044:Call KERNEL32.__wine_kernel_init() ret=7bc6d171 ... 003d:Ret KERNEL32.CreateProcessW() retval=00000001 ret=0047235f ... 0044:Call KERNEL32.CreateProcessW(00000000,0033d6cc L"\"C:\\users\\focht\\Local Settings\\Application Data\\Tibia\\packages\\Tibia\\bin\\client_launcher.exe\" 3",00000000,00000000,00000000,00000410,00000000,00000000,0033d1a0,0033d190) ret=7e72e854 ... 0044:Ret KERNEL32.CreateProcessW() retval=00000001 ret=7e72e854 ... 0044:Call ntdll.RtlInitUnicodeString(0033e75c,00162030 L"\"C:\\users\\focht\\Local Settings\\Application Data\\Tibia\\packages\\Tibia\\bin\\client_launcher.exe\" 6 ") ret=0045e9fe 0044:Ret ntdll.RtlInitUnicodeString() retval=0033e75c ret=0045e9fe ... 0044:Call ntdll.RtlCreateProcessParameters(0033e770,0033e764,00000000,00000000,0033e75c,00000000,00000000,00000000,00000000,00000000) ret=004519b8 ... 0044:Ret ntdll.RtlCreateProcessParameters() retval=00000000 ret=004519b8 ... 0044:Call ntdll.RtlCreateUserProcess(0033e764,00000040,00390000,00000000,00000000,00000000,00000000,00000000,00000000,0033e780) ret=0046fb4d 0044:fixme:ntdll:RtlCreateUserProcess (0x33e764 64 0x390000 (nil) (nil) (nil) 0 (nil) (nil) 0x33e780): stub 0044:Ret ntdll.RtlCreateUserProcess() retval=c0000002 ret=0046fb4d ... 0048:Call KERNEL32.GetStringTypeW(00000001,00162fe8 L"00:52:30: Launching game...\r\n00:52:30: Failed to launch game.\r\n",00000001,005bf46a) ret=7dde5042 --- snip --- Wine currently has the process creation sequence not implemented at native API level (albeit it uses some native API calls). It would require a bit redesign/moving code (dlls/kernel32/process.c:create_process, ...) around but into places that would make Wine more compatible with Windows with regards to process creation (although the heavy lifting is done in Windows kernel). * ntdll.NtCreateProcess * ntdll.RtlCreateUserProcess ... Also related: bug 23451 ("VMWare Thinapps (packaged with version >4.5) and XenoCode wrapped apps fail to run (differences in process creation sequence at native API level)") $ sha1sum Tibia_Setup.exe 50951008ccc402cc32407bfc56a88da873e3e9bd Tibia_Setup.exe $ du -sh Tibia_Setup.exe 5.2M Tibia_Setup.exe $ wine --version wine-3.5-107-gf4573adb0f Regards -- 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.

2 13

[Bug 45844] New: Battleye' s BEDaisy.sys requires correct KeGetCurrentThread implementation
by wine-bugs＠winehq.org 18 Mar '21

18 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=45844 Bug ID: 45844 Summary: Battleye's BEDaisy.sys requires correct KeGetCurrentThread implementation Product: Wine Version: 3.16 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: dereklesho52(a)Gmail.com Distribution: --- Battleye tries to access the KTHREAD structure it gets from KeGetCurrentThread, put because it is not present in our implementation there is a page fault. My implementation on github fixes this issue: https://github.com/Guy1524/wine/commits/battleye-work-stable -- 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.

2 9

[Bug 44496] New: BattlEye 'BEDaisy' kernel service custom imports resolved can't cope with 'ntoskrnl.exe' low-level (wc)string/copy helpers being forwarded to 'msvcrt.dll'
by wine-bugs＠winehq.org 18 Mar '21

18 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=44496 Bug ID: 44496 Summary: BattlEye 'BEDaisy' kernel service custom imports resolved can't cope with 'ntoskrnl.exe' low-level (wc)string/copy helpers being forwarded to 'msvcrt.dll' Product: Wine Version: 3.1 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, follow-up of bug 37355 Small client to reproduce: http://static.tibia.com/download/Tibia_Setup.exe NOTE: Due to a regression with service state/transition handling, the kernel driver service is not started by the helper service anymore (only once upon installation). To work around bug 41670 issue 'wine net stop BEService' command from another console after the window "Starting BattlEye Service..." shows up and wait a bit. The app will detect this and restart the helper service which in turn will start the kernel service. Also suffers from bug 38836 later. --- snip --- $ pwd /home/focht/.wine/drive_c/users/focht/Local Settings/Application Data/Tibia/packages/Tibia/bin $ WINEDEBUG=+tid,+seh,+ntoskrnl,+winedevice,+process,+loaddll,+relay,+module wine ./client_launcher.exe >>log.txt 2>&1 ... 0049:Call ntoskrnl.exe.IoAllocateMdl(00780000,00040409,00000000,00000000,00000000) ret=0080bf37 0049:trace:ntoskrnl:IoAllocateMdl (0x780000, 263177, 0, 0, (nil)) 0049:Call ntdll.RtlAllocateHeap(00110000,00000008,00000120) ret=7ecd1460 0049:Ret ntdll.RtlAllocateHeap() retval=0011cd38 ret=7ecd1460 0049:fixme:ntoskrnl:IoGetCurrentProcess () semi-stub 0049:Ret ntoskrnl.exe.IoAllocateMdl() retval=0011cd38 ret=0080bf37 0049:Call ntoskrnl.exe.MmProbeAndLockPages(0011cd38,00000000,00000001) ret=0080bf37 0049:fixme:ntoskrnl:MmProbeAndLockPages (0x11cd38, 0, 1): stub 0049:Ret ntoskrnl.exe.MmProbeAndLockPages() retval=0000003f ret=0080bf37 0049:Call ntoskrnl.exe.MmMapLockedPagesSpecifyCache(0011cd38,00000000,00000000,00000001,00000000,00000000) ret=0080bf37 0049:fixme:ntoskrnl:MmMapLockedPagesSpecifyCache (0x11cd38, 0, 0, 0x1, 0, 0): stub 0049:Call ntdll.RtlAllocateHeap(00110000,00000000,00040409) ret=7ecd4509 0049:Ret ntdll.RtlAllocateHeap() retval=0011d958 ret=7ecd4509 0049:Call KERNEL32.OpenProcess(001fffff,00000000,00000043) ret=7ecd4534 0049:Ret KERNEL32.OpenProcess() retval=00000040 ret=7ecd4534 0049:Call KERNEL32.ReadProcessMemory(00000040,00780000,0011d958,00040409,00000000) ret=7ecd4567 0049:Ret KERNEL32.ReadProcessMemory() retval=00000001 ret=7ecd4567 0049:Call KERNEL32.CloseHandle(00000040) ret=7ecd458e 0049:Ret KERNEL32.CloseHandle() retval=00000001 ret=7ecd458e 0049:fixme:ntoskrnl:MmMapLockedPagesSpecifyCache Success! 0049:Ret ntoskrnl.exe.MmMapLockedPagesSpecifyCache() retval=0011d958 ret=0080bf37 0049:Call ntoskrnl.exe.ExAllocatePool(00000000,00000068) ret=0080bf37 0049:Call ntdll.RtlAllocateHeap(00110000,00000000,00000068) ret=7ecd3339 0049:Ret ntdll.RtlAllocateHeap() retval=0015f3a8 ret=7ecd3339 0049:trace:ntoskrnl:ExAllocatePoolWithTag 104 pool 0 -> 0x15f3a8 0049:Ret ntoskrnl.exe.ExAllocatePool() retval=0015f3a8 ret=0080bf37 0049:Call ntdll.NtQuerySystemInformation(0000000b,0065f39c,00000000,0065f398) ret=0080732b 0049:Ret ntdll.NtQuerySystemInformation() retval=c0000004 ret=0080732b 0049:Call ntoskrnl.exe.ExAllocatePool(00000000,00001400) ret=007fe2fc 0049:Call ntdll.RtlAllocateHeap(00110000,00000000,00001400) ret=7ecd3339 0049:Ret ntdll.RtlAllocateHeap() retval=0015f6d0 ret=7ecd3339 0049:trace:ntoskrnl:ExAllocatePoolWithTag 5120 pool 0 -> 0x15f6d0 0049:Ret ntoskrnl.exe.ExAllocatePool() retval=0015f6d0 ret=007fe2fc 0049:Call ntdll.NtQuerySystemInformation(0000000b,0015f6d0,00001400,0065f398) ret=008034e1 0049:Ret ntdll.NtQuerySystemInformation() retval=00000000 ret=008034e1 0049:Call ntoskrnl.exe.ExFreePool(0015f6d0) ret=00803229 0049:trace:ntoskrnl:ExFreePoolWithTag 0x15f6d0 0049:Call ntdll.RtlFreeHeap(00110000,00000000,0015f6d0) ret=7ecd3586 0049:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7ecd3586 0049:Ret ntoskrnl.exe.ExFreePool() retval=00000001 ret=00803229 0049:Call ntdll.NtQuerySystemInformation(0000000b,0065f39c,00000000,0065f398) ret=0080732b 0049:Ret ntdll.NtQuerySystemInformation() retval=c0000004 ret=0080732b 0049:Call ntoskrnl.exe.ExAllocatePool(00000000,00001400) ret=007fe2fc 0049:Call ntdll.RtlAllocateHeap(00110000,00000000,00001400) ret=7ecd3339 0049:Ret ntdll.RtlAllocateHeap() retval=0015f6d0 ret=7ecd3339 0049:trace:ntoskrnl:ExAllocatePoolWithTag 5120 pool 0 -> 0x15f6d0 0049:Ret ntoskrnl.exe.ExAllocatePool() retval=0015f6d0 ret=007fe2fc 0049:Call ntdll.NtQuerySystemInformation(0000000b,0015f6d0,00001400,0065f398) ret=008034e1 0049:Ret ntdll.NtQuerySystemInformation() retval=00000000 ret=008034e1 0049:Call ntoskrnl.exe.ExFreePool(0015f6d0) ret=00803229 0049:trace:ntoskrnl:ExFreePoolWithTag 0x15f6d0 0049:Call ntdll.RtlFreeHeap(00110000,00000000,0015f6d0) ret=7ecd3586 0049:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7ecd3586 0049:Ret ntoskrnl.exe.ExFreePool() retval=00000001 ret=00803229 0049:Call ntdll.NtQuerySystemInformation(0000000b,0065f354,00000000,0065f350) ret=0080732b 0049:Ret ntdll.NtQuerySystemInformation() retval=c0000004 ret=0080732b 0049:Call ntoskrnl.exe.ExAllocatePool(00000000,00001400) ret=007fe2fc 0049:Call ntdll.RtlAllocateHeap(00110000,00000000,00001400) ret=7ecd3339 0049:Ret ntdll.RtlAllocateHeap() retval=0015f6d0 ret=7ecd3339 0049:trace:ntoskrnl:ExAllocatePoolWithTag 5120 pool 0 -> 0x15f6d0 0049:Ret ntoskrnl.exe.ExAllocatePool() retval=0015f6d0 ret=007fe2fc 0049:Call ntdll.NtQuerySystemInformation(0000000b,0015f6d0,00001400,0065f350) ret=008034e1 0049:Ret ntdll.NtQuerySystemInformation() retval=00000000 ret=008034e1 0049:Call ntoskrnl.exe.ExFreePool(0015f6d0) ret=00803229 0049:trace:ntoskrnl:ExFreePoolWithTag 0x15f6d0 0049:Call ntdll.RtlFreeHeap(00110000,00000000,0015f6d0) ret=7ecd3586 0049:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7ecd3586 0049:Ret ntoskrnl.exe.ExFreePool() retval=00000001 ret=00803229 0049:Call ntdll.NtQuerySystemInformation(0000000b,0065f358,00000000,0065f354) ret=0080732b 0049:Ret ntdll.NtQuerySystemInformation() retval=c0000004 ret=0080732b 0049:Call ntoskrnl.exe.ExAllocatePool(00000000,00001400) ret=007fe2fc 0049:Call ntdll.RtlAllocateHeap(00110000,00000000,00001400) ret=7ecd3339 0049:Ret ntdll.RtlAllocateHeap() retval=0015f6d0 ret=7ecd3339 0049:trace:ntoskrnl:ExAllocatePoolWithTag 5120 pool 0 -> 0x15f6d0 0049:Ret ntoskrnl.exe.ExAllocatePool() retval=0015f6d0 ret=007fe2fc 0049:Call ntdll.NtQuerySystemInformation(0000000b,0015f6d0,00001400,0065f354) ret=008034e1 0049:Ret ntdll.NtQuerySystemInformation() retval=00000000 ret=008034e1 0049:Call ntoskrnl.exe.ExFreePool(0015f6d0) ret=00803229 0049:trace:ntoskrnl:ExFreePoolWithTag 0x15f6d0 0049:Call ntdll.RtlFreeHeap(00110000,00000000,0015f6d0) ret=7ecd3586 0049:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7ecd3586 0049:Ret ntoskrnl.exe.ExFreePool() retval=00000001 ret=00803229 0049:Call ntdll.NtQuerySystemInformation(0000000b,0065f310,00000000,0065f30c) ret=0080732b 0049:Ret ntdll.NtQuerySystemInformation() retval=c0000004 ret=0080732b 0049:Call ntoskrnl.exe.ExAllocatePool(00000000,00001400) ret=007fe2fc 0049:Call ntdll.RtlAllocateHeap(00110000,00000000,00001400) ret=7ecd3339 0049:Ret ntdll.RtlAllocateHeap() retval=0015f6d0 ret=7ecd3339 0049:trace:ntoskrnl:ExAllocatePoolWithTag 5120 pool 0 -> 0x15f6d0 0049:Ret ntoskrnl.exe.ExAllocatePool() retval=0015f6d0 ret=007fe2fc 0049:Call ntdll.NtQuerySystemInformation(0000000b,0015f6d0,00001400,0065f30c) ret=008034e1 0049:Ret ntdll.NtQuerySystemInformation() retval=00000000 ret=008034e1 0049:Call ntoskrnl.exe.ExFreePool(0015f6d0) ret=00803229 0049:trace:ntoskrnl:ExFreePoolWithTag 0x15f6d0 0049:Call ntdll.RtlFreeHeap(00110000,00000000,0015f6d0) ret=7ecd3586 0049:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7ecd3586 0049:Ret ntoskrnl.exe.ExFreePool() retval=00000001 ret=00803229 --- snip --- The (heavily obfuscated) kernel driver uses its own custom imports resolver. It basically walks the module list using 'NtQuerySystemInformation( SystemModuleInformation, ...)' and processes the export table of 'ntoskrnl.exe' and later 'fltmgr.sys' in order to resolve some needed functions. The resolver is rather simplistic and can't deal with Wine's forwarded exports to 'msvcrt'. Native Windows kernel doesn't do this. --- snip --- ... DbgPrint says: The procedure entry point wcsncmp could not be located in the module ntoskrnl.exe Ret driver init 0x7fdf6e (obj=0x11cb58,str=L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\BEDaisy") retval=c0000183 0049:trace:winedevice:init_driver init done for L"BEDaisy" obj 0x11cb58 0049:trace:winedevice:init_driver - DriverInit = 0x7fdf6e 0049:trace:winedevice:init_driver - DriverStartIo = (nil) 0049:trace:winedevice:init_driver - DriverUnload = (nil) 0049:trace:winedevice:init_driver - MajorFunction[0] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[1] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[2] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[3] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[4] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[5] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[6] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[7] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[8] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[9] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[10] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[11] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[12] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[13] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[14] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[15] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[16] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[17] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[18] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[19] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[20] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[21] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[22] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[23] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[24] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[25] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[26] = 0x7ecd1b10 0049:trace:winedevice:init_driver - MajorFunction[27] = 0x7ecd1b10 0049:Call ntdll.RtlFreeUnicodeString(0011cb74) ret=7ecd1d12 0049:Ret ntdll.RtlFreeUnicodeString() retval=0011cb74 ret=7ecd1d12 0049:Call ntdll.RtlFreeUnicodeString(0011cc0c) ret=7ecd1d26 0049:Ret ntdll.RtlFreeUnicodeString() retval=0011cc0c ret=7ecd1d26 0049:Call ntdll.RtlFreeHeap(00110000,00000000,0011cb48) ret=7ecd1d46 0049:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7ecd1d46 0049:Ret ntoskrnl.exe.IoCreateDriver() retval=c0000183 ret=7effb7fc 0049:err:winedevice:async_create_driver failed to create driver L"BEDaisy": c0000183 --- snip --- NOTE: This is a similar problem domain as bug 37852 ("Sentinel HASP 'hardlock.sys' kernel driver custom imports resolver can't cope with many 'ntoskrnl.exe' functions being fowarded to 'ntdll.dll' (Minitab 16 fails to start)". Although this driver requires a much smaller set of (msvcrt) functions. * native API (ntdll) -> bug 37852 * msvcrt -> this one Source: https://source.winehq.org/git/wine.git/blob/354fa7eb7921c3317e7943c18871feb… --- snip --- 1484 @ cdecl -private wcsncmp(wstr wstr long) msvcrt.wcsncmp --- snip --- The driver requires the following set of functions not be forwarded: * wcsncmp * _wcsnicmp * _strnicmp * memcpy * memset * _stricmp Wine should reimplement the low-level string/copy helpers in 'ntoskrnl' in same way as it is done for 'ntdll' core module (NTDLL_foobar). Source: https://source.winehq.org/git/wine.git/blob/354fa7eb7921c3317e7943c18871feb… --- snip --- 1457 @ cdecl -private wcsncmp(wstr wstr long) NTDLL_wcsncmp --- snip --- https://source.winehq.org/git/wine.git/blob/354fa7eb7921c3317e7943c18871feb… --- snip --- 157 /********************************************************************* 158 * wcsncmp (NTDLL.@) 159 */ 160 INT __cdecl NTDLL_wcsncmp( LPCWSTR str1, LPCWSTR str2, INT n ) 161 { 162 return strncmpW( str1, str2, n ); 163 } --- snip --- With these things fixed, the driver runs further - into next problems. $ sha1sum Tibia_Setup.exe 50951008ccc402cc32407bfc56a88da873e3e9bd Tibia_Setup.exe $ du -sh Tibia_Setup.exe 5.2M Tibia_Setup.exe $ wine --version wine-3.1-193-g354fa7eb79 Regards -- 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.

2 10

[Bug 44811] New: BattlEye 'BEDaisy' kernel service requires _chkstk implementation.
by wine-bugs＠winehq.org 18 Mar '21

18 Mar '21

https://bugs.winehq.org/show_bug.cgi?id=44811 Bug ID: 44811 Summary: BattlEye 'BEDaisy' kernel service requires _chkstk implementation. Product: Wine Version: 3.4 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: leslie_alistair(a)hotmail.com Distribution: --- When the stack goes over a 4k on x86 or 8k for x64 boundary then this function is used to resolve this issue. https://msdn.microsoft.com/en-us/library/ms648426(v=vs.85).aspx -- 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.

2 12