https://bugs.winehq.org/show_bug.cgi?id=44924
Bug ID: 44924 Summary: StarForce v3 kernel drivers need ntoskrnl.IoCreateSynchronizationEvent to return a non-NULL handle Product: Wine Version: 3.5 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs@winehq.org Reporter: focht@gmx.net Distribution: ---
Hello folks,
as it says, the driver expects something non-NULL.
It can be a magic number for now since Wine doesn't implement any "kernel" synchronization objects nor wait primitives.
Prior to the test-patch:
--- snip --- ... 0036:Call driver init 0x785300 (obj=0x11cc28,str=L"\Registry\Machine\System\CurrentControlSet\Services\sfhlp02") ... 0036:Call ntoskrnl.exe.IoCreateDevice(0011cc28,00000000,0065fc84,00009000,00000000,00000000,00783004) ret=007850f8 0036:trace:ntoskrnl:IoCreateDevice (0x11cc28, 0, L"\Device\sfhlp02", 36864, 0, 0, 0x783004) ... 0036:Ret ntoskrnl.exe.IoCreateDevice() retval=00000000 ret=007850f8 ... 0036:trace:ntoskrnl:IoCreateSymbolicLink L"\DosDevices\sfhlp02" -> L"\Device\sfhlp02" ... 0036:Call ntoskrnl.exe.IoCreateDevice(0011cc28,00000000,0065fc7c,00009001,00000000,00000000,00783008) ret=0078513f 0036:trace:ntoskrnl:IoCreateDevice (0x11cc28, 0, L"\Device\sfhlp02i", 36865, 0, 0, 0x783008) ... 0036:Ret ntoskrnl.exe.IoCreateDevice() retval=00000000 ret=0078513f 0036:Call ntoskrnl.exe.IoCreateSymbolicLink(0065fc74,0065fc7c) ret=0078515b 0036:trace:ntoskrnl:IoCreateSymbolicLink L"\DosDevices\sfhlp02i" -> L"\Device\sfhlp02i" ... 0036:Call ntoskrnl.exe.IoCreateSynchronizationEvent(0065fc80,0065fc8c) ret=00785414 0036:fixme:ntoskrnl:IoCreateSynchronizationEvent (0x65fc80 0x65fc8c) stub 0036:Ret ntoskrnl.exe.IoCreateSynchronizationEvent() retval=00000000 ret=00785414 ... 0036:Call ntoskrnl.exe.IoDeleteDevice(0011ce58) ret=00785258 ... 0036:Ret ntoskrnl.exe.IoDeleteDevice() retval=00000001 ret=00785258 ... 0036:Call ntoskrnl.exe.IoDeleteDevice(0011cd98) ret=0078526d ... 0036:Ret ntoskrnl.exe.IoDeleteDevice() retval=00000001 ret=0078526d 0036:Ret driver init 0x785300 (obj=0x11cc28,str=L"\Registry\Machine\System\CurrentControlSet\Services\sfhlp02") retval=c000009a ... --- snip ---
With a patch that returns 0xcafebabe, resulting in driver running further and calling 'ntoskrnl.exe.KeWaitForSingleObject( 0xcafebabe, ...)':
--- snip --- ... 0035:Call driver init 0x785300 (obj=0x11caf0,str=L"\Registry\Machine\System\CurrentControlSet\Services\sfhlp02") ... 035:Call ntoskrnl.exe.IoCreateSynchronizationEvent(0065fc80,0065fc8c) ret=00785414 0035:fixme:ntoskrnl:IoCreateSynchronizationEvent (0x65fc80 0x65fc8c) stub 0035:Ret ntoskrnl.exe.IoCreateSynchronizationEvent() retval=cafebabe ret=00785414 0035:Call ntoskrnl.exe.KeEnterCriticalRegion() ret=0078542c 0035:fixme:ntoskrnl:KeEnterCriticalRegion : stub 0035:Ret ntoskrnl.exe.KeEnterCriticalRegion() retval=00000031 ret=0078542c 0035:Call ntoskrnl.exe.KeWaitForSingleObject(cafebabe,00000000,00000000,00000000,00000000) ret=00785437 0035:fixme:ntoskrnl:KeWaitForSingleObject stub: 0xcafebabe, 0, 0, 0, (nil) 0035:Ret ntoskrnl.exe.KeWaitForSingleObject() retval=c0000002 ret=00785437 0035:Call ntoskrnl.exe.RtlInitUnicodeString(0065fc78,007853ac L"\Callback\StarForceCreateThread") ret=00785442 0035:Call ntdll.RtlInitUnicodeString(0065fc78,007853ac L"\Callback\StarForceCreateThread") ret=7bc7f41b 0035:Ret ntdll.RtlInitUnicodeString() retval=0065fc78 ret=7bc7f41b 0035:Ret ntoskrnl.exe.RtlInitUnicodeString() retval=0065fc78 ret=00785442 0035:Call ntoskrnl.exe.ExCreateCallback(0065fc88,0065fc60,00000000,00000001) ret=00785472 0035:fixme:ntoskrnl:ExCreateCallback (0x65fc88, 0x65fc60, 0, 1): stub 0035:Ret ntoskrnl.exe.ExCreateCallback() retval=c0000002 ret=00785472 0035:Call ntoskrnl.exe.ZwClose(00783014) ret=007854ee 0035:Call ntdll.NtClose(00783014) ret=7bc7f41b 0035:Ret ntdll.NtClose() retval=c0000008 ret=7bc7f41b 0035:Ret ntoskrnl.exe.ZwClose() retval=c0000008 ret=007854ee 0035:Call ntoskrnl.exe.KeLeaveCriticalRegion() ret=007854f4 0035:fixme:ntoskrnl:KeLeaveCriticalRegion : stub 0035:Ret ntoskrnl.exe.KeLeaveCriticalRegion() retval=00000031 ret=007854f4 0035:Call ntoskrnl.exe.IoAllocateErrorLogEntry(0011caf0,00000030) ret=0078103a 0035:fixme:ntoskrnl:IoAllocateErrorLogEntry stub: 0x11caf0, 48 0035:Ret ntoskrnl.exe.IoAllocateErrorLogEntry() retval=00000000 ret=0078103a ... 0035:Ret driver init 0x785300 (obj=0x11caf0,str=L"\Registry\Machine\System\CurrentControlSet\Services\sfhlp02") retval=c0000002 ... 0035:Ret ntoskrnl.exe.IoCreateDriver() retval=c0000002 ret=7effb786 0035:err:winedevice:async_create_driver failed to create driver L"sfhlp02": c0000002 --- snip ---
The driver is still failing, but that's another problem.
Anyway, at some point in future one should think about properly emulating kernel-level synchronization objects. It's not very hard to do. Wine doesn't need to follow/mimic the exact structure layouts for Windows kernel objects by design. The structs would just wrap native API synchronization objects and the actual sync APIs, such as KeWaitXXX, KeEnterXXX ... would call corresponding native NtXXX API (NtWaitXXX, ...). See also bug 44588 (ntoskrnl.exe.KeWaitForMultipleObjects) and related ones.
$ sha1sum tmsunrisedemo_setup.exe 2d44577a71718464c595d9da91a017fb0914afc4 tmsunrisedemo_setup.exe
$ du -sh tmsunrisedemo_setup.exe 210M tmsunrisedemo_setup.exe
$ wine --version wine-3.5-91-g3263d51a1f
Regards