http://bugs.winehq.org/show_bug.cgi?id=30155
Bug #: 30155 Summary: secdrv.sys from SafeDisc v2.05.030 does not work Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl AssignedTo: wine-bugs@winehq.org ReportedBy: stefan@codeweavers.com Classification: Unclassified
Created attachment 39336 --> http://bugs.winehq.org/attachment.cgi?id=39336 service,relay,winedevice,ntoskrnl log
SafeDisc 2.05.030 does not work out of the box. The user-visible symptom is that the application exits with exit code 0 without any output. This affects for example the Command and Conquer Red Alert 2 installer, which is safedisc protected for some reason.
The problem seems to be related to the specific secdrv.sys version. If I take a secdrv.sys from a newer safedisc version(e.g. 2.40.010 from the RA2 Yuri's revenge expansion) and put it in C:\windows\system32\drivers, the installer works.
ProtectId says:
Scanning -> D:\Setup\Setup.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 1308863 (013F8BFh) Byte(s) -> File has 733375 (0B30BFh) bytes of appended data starting at offset 08C800h [File Heuristics] -> Flag : 00000000000000000100000000100111 (0x00004027) [!] Safedisc v2.05.030 detected ! [i] Appended data contents.... [.] o: 0x0008C828 / t: <0x00000001> <0x00000000> <0x00000001> / s: 00194947 byte(s) -> ~de7bc4.tmp [.] o: 0x000BC1D2 / t: <0x00000001> <0x00000000> <0x0000044C> / s: 00030208 byte(s) -> clcd32.dll [.] o: 0x000C37F9 / t: <0x00000001> <0x00000000> <0x0000044C> / s: 00006784 byte(s) -> clcd16.dll [.] o: 0x000C529D / t: <0x00000001> <0x00000000> <0x0000044D> / s: 00067584 byte(s) -> mcp.dll [.] o: 0x000D5AC5 / t: <0x00000001> <0x00000000> <0x00000000> / s: 00327220 byte(s) -> ~df394b.tmp [.] o: 0x00125920 / t: <0x00000001> <0x00000000> <0x00000002> / s: 00034304 byte(s) -> drvmgt.dll [.] o: 0x0012DF47 / t: <0x00000001> <0x00000000> <0x00000002> / s: 00018768 byte(s) -> secdrv.sys [.] o: 0x001328BF / t: <0x00000001> <0x00000000> <0x00000000> / s: 00053248 byte(s) -> ~ef7194.tmp [CompilerDetect] -> Visual C++ 6.0 - Scan Took : 0.640 Second(s)
The md5sum of the broken secdrv.sys is XXX. The md5sum of the working 2.40.010 driver is f376a1580204e47f37a721e1cbc5582a.
I am attaching a +relay,+service,+winedevice+ntoskrnl log of a failed run of the setup tool.
http://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #1 from Stefan Dösinger stefan@codeweavers.com 2012-03-13 05:08:08 CDT --- Sorry, I forgot to add the broken secdrv.sys md5sum: $ md5sum SECDRV.SYS 2fb6db76ee67f00df345e57e71c6ca2b SECDRV.SYS
http://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #2 from Stefan Dösinger stefan@codeweavers.com 2012-03-13 05:21:29 CDT --- I wanted to file a similar bug for Age of Empires 2: The Conquerors(Safedisc v1.50.020), but I cannot reproduce the problem with that safedisc version any more. Maybe I had a savedisc v2.05.030 infected wineprefix when I tested aoe2.
http://bugs.winehq.org/show_bug.cgi?id=30155
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|ntoskrnl |-unknown Version|unspecified |1.4
http://bugs.winehq.org/show_bug.cgi?id=30155
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
http://bugs.winehq.org/show_bug.cgi?id=30155
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #3 from Anastasius Focht focht@gmx.net 2012-03-13 16:23:00 CDT --- Hello Stefan,
is that log file from a single game installation in clean WINEPREFIX?
There exist two safedisc driver binaries, one in system32/drivers and one dynamically extracted from setup.exe.
--- snip --- 0009:Call KERNEL32.CreateFileA(0032f21c "D:\Setup\Setup.exe",80000000,00000001,00000000,00000003,00000000,00000000) ret=1000119d 0009:Ret KERNEL32.CreateFileA() retval=0000002c ret=1000119d ... 0009:Call KERNEL32.CreateFileA(0032ee8c "C:\users\stefan\Temp\~ef87a1\secdrv.sys",c0000000,00000000,00000000,00000002,10000000,00000000) ret=1000424d 0009:Ret KERNEL32.CreateFileA() retval=00000038 ret=1000424d ... 0009:Call KERNEL32.SetFilePointer(0000002c,0012df47,00000000,00000000) ret=1000441f 0009:Ret KERNEL32.SetFilePointer() retval=0012df47 ret=1000441f 0009:Call KERNEL32.ReadFile(0000002c,00494940,00000800,0032ee50,00000000) ret=1000451a 0009:Ret KERNEL32.ReadFile() retval=00000001 ret=1000451a 0009:Call KERNEL32.WriteFile(00000038,00494940,00000800,0032ee5c,00000000) ret=10004637 0009:Ret KERNEL32.WriteFile() retval=00000001 ret=10004637 ... 0009:Call KERNEL32.CloseHandle(00000038) ret=10004382 0009:Ret KERNEL32.CloseHandle() retval=00000001 ret=10004382 ... 0009:Call KERNEL32.CloseHandle(0000002c) ret=10001278 0009:Ret KERNEL32.CloseHandle() retval=00000001 ret=10001278 --- snip ---
--- snip --- 0018:Call KERNEL32.CreateProcessW(00000000,00119630 L"C:\windows\system32\winedevice.exe Secdrv",00000000,00000000,00000000,00000400,00540000,00000000,0094e528,0094e56c) ret=7ed545f8 ... 002d:Call KERNEL32.LoadLibraryW(0011ab10 L"C:\windows\system32\drivers\\SECDRV.SYS") ret=7ed5d9ad ... 002d:Ret KERNEL32.LoadLibraryW() retval=00540000 ret=7ed5d9ad ... trace:winedevice:load_driver_module L"C:\windows\system32\drivers\\SECDRV.SYS": relocating from 0x10000 to 0x540000 --- snip ---
I don't see any file copy so it seems you probably had at least one (failed) run prior that might have caused a file copy to system32/drivers.
There is only a single ioctl after driver init:
--- snip --- trace:ntoskrnl:process_ioctl ioctl ef002407 device 0x11aab8 in_size 1300 out_size 3096 ... 002d:Call driver dispatch 0x540402 (device=0x11aab8,irp=0x53e7c0) ... trace:ntoskrnl:__regs_IofCompleteRequest 0x53e7c0 0 ... 002d:Ret driver dispatch 0x540402 (device=0x11aab8,irp=0x53e7c0) retval=00000000 --- snip ---
before the service gets shut down again.
It would be helpful if you hexdump the input buffer passed to driver via ioctl code 0xef002407 (first 8 DWORDs are enough).
Additionally can you send me the driver binary (email).
Regards
http://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #4 from Stefan Dösinger stefan@codeweavers.com 2012-03-14 05:41:28 CDT --- It was an almost clean prefix. I ran the same .exe file once before generating the log, mostly to make sure the symptom shows up as expected. I'll add the debug code you're asking for and regenerate the log.
http://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #5 from Stefan Dösinger stefan@codeweavers.com 2012-03-14 06:15:16 CDT --- Created attachment 39351 --> http://bugs.winehq.org/attachment.cgi?id=39351 log with extra debugging and driver copy
Hi,
Here's the log you requested. This time the driver copy happens:
--- snip --- 0009:Call KERNEL32.CopyFileA(0032f0c4 "C:\users\stefan\Temp\~ef87a1\SECDRV.SYS",0032eec4 "C:\windows\system32\drivers\\SECDRV.SYS",00000000) ret=003317db 0009:Ret KERNEL32.CopyFileA() retval=00000001 ret=003317db --- snip ---
Extra dumping of the ioctl input buffer was also added.
http://bugs.winehq.org/show_bug.cgi?id=30155
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation Component|-unknown |ntoskrnl Summary|secdrv.sys from SafeDisc |SafeDisc v2.05.030 fails |v2.05.030 does not work |due to driver dispatch | |routine status and | |irp.IoStatus.u.Status | |differing (Command & | |Conquer: Red Alert 2)
--- Comment #6 from Anastasius Focht focht@gmx.net 2012-03-24 06:27:28 CDT --- Hello Stefan,
I bought the game for few bucks as this stuff can only be properly analyzed by live debugging ;-) Thanks for the logs.
--- snip --- 0009:Call KERNEL32.CreateFileA(0032f1dc "\\.\Secdrv",c0000000,00000003,00000000,00000003,00000080,00000000) ret=0033107b ... 0009:Ret KERNEL32.CreateFileA() retval=0000002c ret=0033107b 0009:Call KERNEL32.DeviceIoControl(0000002c,ef002407,009b1fb0,00000514,009b24c4,00000c18,0032f2e4,00000000) ret=003310d4 ... trace:ntoskrnl:process_ioctl ioctl ef002407 device 0x11aac8 in_size 1300 out_size 3096 err:ntoskrnl:process_ioctl Input buffer 0: 00000002 err:ntoskrnl:process_ioctl Input buffer 1: 00000002 err:ntoskrnl:process_ioctl Input buffer 2: 00000000 err:ntoskrnl:process_ioctl Input buffer 3: 0000003e err:ntoskrnl:process_ioctl Input buffer 4: db8ce543 err:ntoskrnl:process_ioctl Input buffer 5: 4f190d3a err:ntoskrnl:process_ioctl Input buffer 6: a82e94fd err:ntoskrnl:process_ioctl Input buffer 7: 3cbb7c84 0031:Call ntdll.NtGetTickCount() ret=7ec9b650 0031:Ret ntdll.NtGetTickCount() retval=0000045b ret=7ec9b650 0031:Call driver dispatch 0x540402 (device=0x11aac8,irp=0x53e7c0) trace:ntoskrnl:__regs_IofCompleteRequest 0x53e7c0 0 trace:ntoskrnl:IoCompleteRequest 0x53e7c0 0 0031:Ret driver dispatch 0x540402 (device=0x11aac8,irp=0x53e7c0) retval=00000000 ... 0009:Ret KERNEL32.DeviceIoControl() retval=00000000 ret=003310d4 --- snip ---
The SafeDisc driver input buffer (structures similar as of http://www.winehq.org/pipermail/wine-patches/2002-April/002146.html)
--- snip --- typedef struct _SECDRV_IOC_IN_BUFFER { DWORD dwVersionMajor; DWORD dwVersionMinor; DWORD dwVersionPatch;
DWORD dwCommand; BYTE bVerificationData[0x400];
DWORD cbUserData; BYTE bUserData[0x100]; } SECDRV_IOC_IN_BUFFER, *PSECDRV_IOC_IN_BUFFER; --- snip ---
--- snip --- err:ntoskrnl:process_ioctl Input buffer 0: 00000002 err:ntoskrnl:process_ioctl Input buffer 1: 00000002 err:ntoskrnl:process_ioctl Input buffer 2: 00000000 --- snip ---
driver version 2.2.0 (SafeDisc 2.5.30)
--- snip --- err:ntoskrnl:process_ioctl Input buffer 3: 0000003e --- snip ---
-> SECDRV_CMD_SETUP
0x3E handler:
In the "setup" phase handler the driver checks for:
in-buffer, out-buffer ptrs != NULL in-buffer == 0x514 out-buffer == 0xC18
In the next step the client side KeTickCount (KSYSTEM_TIME) tick value which is in the first DWORD (buffer 4) is decoded. Basically it's an XOR loop with predefined constants on client and driver side.
--- snip --- err:ntoskrnl:process_ioctl Input buffer 4: db8ce543 err:ntoskrnl:process_ioctl Input buffer 5: 4f190d3a err:ntoskrnl:process_ioctl Input buffer 6: a82e94fd err:ntoskrnl:process_ioctl Input buffer 7: 3cbb7c84 --- snip ---
There is nothing special about the input data, despite reading the KeTickCount on server side it doesn't compare it in setup phase.
Instead the driver fills the return buffer:
--- snip --- typedef struct _SECDRV_IOC_OUT_BUFFER { DWORD dwVersionMajor; DWORD dwVersionMinor; DWORD dwVersionPatch;
BYTE bVerificationData[0x400];
DWORD cbUserData; BYTE bUserData[0x200]; } SECDRV_IOC_OUT_BUFFER, *PSECDRV_IOC_OUT_BUFFER; --- snip ---
--- snip --- Address Value 00127D28 00000002 ; major 00127D2C 00000002 ; minor 00127D30 00000000 ; patchlevel 00127D34 DB9D783C ; tickcount ^ XOR'd with seeds 00127D38 4F190D3A ; XOR seed1 00127D3C A82E94FD ; XOR seed2 00127D40 3CBB7C84 ; XOR seed3 --- snip ---
The "KeTickCount read is done using following snippet:
--- snip --- 00542007 A1 88025400 MOV EAX,DWORD PTR DS:[<&ntoskrnl_exe.KeTickCount>] 0054200C 8945 F0 MOV DWORD PTR SS:[EBP-10],EAX 0054200F 8B45 F0 MOV EAX,DWORD PTR SS:[EBP-10] 00542012 8B40 04 MOV EAX,DWORD PTR DS:[EAX+4] ; High1Time 00542015 8945 F8 MOV DWORD PTR SS:[EBP-8],EAX 00542018 8B45 F0 MOV EAX,DWORD PTR SS:[EBP-10] 0054201B 8B00 MOV EAX,DWORD PTR DS:[EAX] ; LowPart 0054201D 8945 F4 MOV DWORD PTR SS:[EBP-0C],EAX 00542020 8B45 F0 MOV EAX,DWORD PTR SS:[EBP-10] 00542023 8B4D F8 MOV ECX,DWORD PTR SS:[EBP-8] ; High1Time 00542026 3B48 08 CMP ECX,DWORD PTR DS:[EAX+8] ; High1Time == High2Time (if (KeTickCount->High1Time == KeTickCount.High2Time) break) 00542029 75 E4 JNE SHORT 0054200F --- snip ---
cbUserData = 0x5278D11B
--- snip --- 00543820 8B45 FC MOV EAX,DWORD PTR SS:[EBP-4] 00543823 C700 1BD17852 MOV DWORD PTR DS:[EAX],5278D11B --- snip ---
There was not much "business logic" code after filling the output buffer. Many obfuscation related jumps and call/rets to make debugging a misery ;-)
At a certain point the driver set:
irp.IoStatus.Information = 0
--- snip --- 00541E46 66:8365 F0 00 AND WORD PTR SS:[EBP-10],0000 --- snip ---
and irp.IoStatus.u.Status = 0xC0000001 (STATUS_UNSUCCESSFUL)
--- snip --- 00540978 8B45 0C MOV EAX,DWORD PTR SS:[EBP+0C] 0054097B C700 010000C0 MOV DWORD PTR DS:[EAX],C0000001 00540981 EB 07 JMP SHORT 0054098A --- snip ---
After several hours of debugging I came to conclusion it doesn't have anything to do with the client input, especially the KeTickCount field encoded in buffer. This is done on purpose by driver.
The IoCompleteRequest() call from driver within dispatch routine should not change the returned IRP status field, it's basically a no-op in this case.
The problem is that Wine doesn't anticipate a case where a driver returns success (0) from dispatch function while the irp.IoStatus.u.Status is non-zero. Wine only looks at irp.IoStatus.u.Status.
http://source.winehq.org/git/wine.git/blob/70dcc417601e2e3e9ae1215690f22f7b1...
--- snip --- 136 /* process an ioctl request for a given device */ 137 static NTSTATUS process_ioctl( DEVICE_OBJECT *device, ULONG code, void *in_buff, ULONG in_size, 138 void *out_buff, ULONG *out_size ) 139 { 140 IRP irp; ... 185 KeQueryTickCount( &count ); /* update the global KeTickCount */ 186 187 if (TRACE_ON(relay)) 188 DPRINTF( "%04x:Call driver dispatch %p (device=%p,irp=%p)\n", 189 GetCurrentThreadId(), dispatch, device, &irp ); 190 191 status = dispatch( device, &irp ); 192 193 if (TRACE_ON(relay)) 194 DPRINTF( "%04x:Ret driver dispatch %p (device=%p,irp=%p) retval=%08x\n", 195 GetCurrentThreadId(), dispatch, device, &irp, status ); 196 197 *out_size = (irp.IoStatus.u.Status >= 0) ? irp.IoStatus.Information : 0; 198 if ((code & 3) == METHOD_BUFFERED) 199 { 200 memcpy( out_buff, irp.AssociatedIrp.SystemBuffer, *out_size ); 201 HeapFree( GetProcessHeap(), 0, irp.AssociatedIrp.SystemBuffer ); 202 } 203 return irp.IoStatus.u.Status; 204 } --- snip ---
Wine looks at irp.IoStatus.u.Status >= 0, resets out_size hence the out buffer is never copied and ioctl fails due to returned status.
Microsoft has some information on handling of IRP's:
http://support.microsoft.com/kb/320275
This is our case:
--- snip --- Scenario 5: Complete the IRP in the dispatch routine This scenario shows how to complete an IRP in the dispatch routine.
Important When you complete an IRP in the dispatch routine, the return status of the dispatch routine should match the status of the value that is set in the IoStatus block of the IRP (Irp->IoStatus.Status).
NTSTATUS DispatchRoutine_5( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp ) { // // <-- Process the IRP here. // Irp->IoStatus.Status = STATUS_XXX; Irp->IoStatus.Information = YYY; IoCompletRequest(Irp, IO_NO_INCREMENT); return STATUS_XXX; } --- snip ---
The SafeDisc driver doesn't follow Irp->IoStatus.Status == return dispatch status scheme but the ioctl yet succeeds on Windows (this as this game has been reported to work on Windows). I'm not sure if this is intentional or oversight.
For testing I've modified the status evaluation code.
If the returned dispatch function status doesn't match Irp.IoStatus.u.Status then set irp.IoStatus.u.Status to dispatch status (0) and don't reset out_size. Still have it copy irp.AssociatedIrp.SystemBuffer to out_buff ((code & 3) == METHOD_BUFFERED).
With these changes the SafeDisc driver works. You will see a lot of ioctls following the initial setup phase.
The game installer requires 16bpp mode setting in X server, be prepared.
Regards
http://bugs.winehq.org/show_bug.cgi?id=30155
Charles Davis cdavis@mymail.mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cdavis@mymail.mines.edu
http://bugs.winehq.org/show_bug.cgi?id=30155
Johan Gardhage johan.gardhage@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johan.gardhage@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30155
Axper Jan tdsbug@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tdsbug@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #7 from Anastasius Focht focht@gmx.net --- Hello folks,
revisiting, obviously still present.
$ wine --version wine-1.7.26-23-g618f4f2
Regards
https://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #8 from Anastasius Focht focht@gmx.net --- Hello folks,
fortunately this bug got attention by Wine-staging project hence chances are better now that the SafeDisc issue will be fixed and analysis was not wasted time :)
Also needed by Tages DRM scheme, mentioned here: https://bugs.winehq.org/show_bug.cgi?id=33849#c13
--- quote --- * Tages gets stuck because dispatch routine status and irp.IoStatus.u.Status are different (bug 30155). Patch:
https://github.com/wine-compholio/wine-staging/tree/master/patches/ntoskrnl-... --- quote ---
Regards
https://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #9 from Anastasius Focht focht@gmx.net --- Hello folks,
revisiting, still present.
The patch from Wine-staging doesn't work here.
I checked my old bugfix branch and it still works. Hint: 'out_size' Maybe Tagès (bug 33849) runs even further with it :)
$ wine --version wine-1.7.34-60-gd6450cf
Regards
https://bugs.winehq.org/show_bug.cgi?id=30155
Olivier Diotte olivier@diotte.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |olivier@diotte.ca
https://bugs.winehq.org/show_bug.cgi?id=30155
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
https://bugs.winehq.org/show_bug.cgi?id=30155
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |imwellcushtymelike@gmail.co | |m
--- Comment #10 from Ken Sharp imwellcushtymelike@gmail.com --- No change in Wine-staging 1.9.12 (unless there's something new). Installer exits silently.
https://bugs.winehq.org/show_bug.cgi?id=30155
Josh Holland anowlcalledjosh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |anowlcalledjosh@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=30155
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #11 from Fabian Maurer dark.shadow4@web.de --- Does the error still exist in wine 3.4?
https://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #12 from Anastasius Focht focht@gmx.net --- Hello,
--- quote --- Does the error still exist in wine 3.4? --- quote ---
Wine's code has been reworked in recent years to match native Windows kernel I/O manager behaviour more closely (I/O completion process and IRP result delivery) but the problem is still present, yes.
I might take another shot at this driver in future, albeit low prio. Not very fun to debug though.
--- snip --- ... 0030:Call KERNEL32.DeviceIoControl(00000034,ef002407,009b2000,00000514,009b2514,00000c18,0033f324,00000000) ret=003410d4 ... 0038:trace:ntoskrnl:dispatch_ioctl ioctl ef002407 device 0x11cd30 file 0x11ca40 in_size 4396 out_size 3096
0038:Call ntdll.RtlAllocateHeap(00110000,00000000,00000c18) ret=7ec1681f 0038:Ret ntdll.RtlAllocateHeap() retval=0011b9e8 ret=7ec1681f
0038:trace:ntoskrnl:IoBuildDeviceIoControlRequest ef002407, 0x11cd30, 0x11cf00, 1300, 0x11b9e8, 3096, 0, (nil), (nil) 0038:trace:ntoskrnl:IoAllocateIrp 1, 0 0038:Call ntdll.RtlAllocateHeap(00110000,00000000,00000094) ret=7ec1921a 0038:Ret ntdll.RtlAllocateHeap() retval=0011c608 ret=7ec1921a 0038:trace:ntoskrnl:ExAllocatePoolWithTag 148 pool 0 -> 0x11c608
0038:trace:ntoskrnl:IoInitializeIrp 0x11c608, 148, 1 0038:Call ntdll.RtlReAllocateHeap(00110000,00000010,0011cf00,00000514) ret=7ec16944 0038:Ret ntdll.RtlReAllocateHeap() retval=0011cf00 ret=7ec16944 0038:Call ntdll.NtGetTickCount() ret=7ec19b33 0038:Ret ntdll.NtGetTickCount() retval=02349aba ret=7ec19b33
0038:Call driver dispatch 0x780402 (device=0x11cd30,irp=0x11c608) irp->IoStatus.u.Status=00000000 ... 0038:trace:ntoskrnl:__regs_IofCompleteRequest 0x11c608 0 0038:trace:ntoskrnl:IoCompleteRequest 0x11c608 0 irp->IoStatus.u.Status=c0000001 ... 0038:trace:ntoskrnl:IoCompleteRequest calling 0x7ec15ea9( 0x11cd30, 0x11c608, 0x48 ) ... 0038:trace:ntoskrnl:IoCompleteRequest CompletionRoutine returned 0, irp->IoStatus.u.Status=c0000001
0030:Ret KERNEL32.DeviceIoControl() retval=00000000 ret=003410d4 ... --- snip ---
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/different-w...
Even though the kernel driver doesn't follow the recommendation of matching return status when completing the IRP in the dispatch routine, there has to be a reason for irp.IoStatus.u.Status = 0xC0000001 (STATUS_UNSUCCESSFUL).
Regards
https://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #13 from Charles Davis cdavis5x@gmail.com --- Created attachment 65976 --> https://bugs.winehq.org/attachment.cgi?id=65976 ntoskrnl: Return driver dispatch result to caller.
https://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #14 from Charles Davis cdavis5x@gmail.com --- Created attachment 65977 --> https://bugs.winehq.org/attachment.cgi?id=65977 ntoskrnl: Always copy the buffer for non-METHOD_BUFFERED ioctls.
https://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #15 from Charles Davis cdavis5x@gmail.com --- Created attachment 65978 --> https://bugs.winehq.org/attachment.cgi?id=65978 server: Delay completing a synchronous IRP.
https://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #16 from Charles Davis cdavis5x@gmail.com --- Created attachment 65979 --> https://bugs.winehq.org/attachment.cgi?id=65979 server: Return the driver's 'Information' from ioctl.
https://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #17 from Charles Davis cdavis5x@gmail.com --- These four patches should accommodate the broken behavior of SafeDisc here. With these, I was actually able to install RA2!
https://bugs.winehq.org/show_bug.cgi?id=30155
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=30155
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/ntoskrnl-safedis | |c-2
https://bugs.winehq.org/show_bug.cgi?id=30155
--- Comment #18 from Fabian Maurer dark.shadow4@web.de --- *** Bug 44766 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=30155
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |NEW
--- Comment #19 from Gijs Vermeulen gijsvrm@gmail.com --- The staging patchset has been disabled for a while, removing STAGED status.
https://bugs.winehq.org/show_bug.cgi?id=30155
Linards linards.liepins@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |linards.liepins@gmail.com
--- Comment #20 from Linards linards.liepins@gmail.com --- Is this issue still present?
https://bugs.winehq.org/show_bug.cgi?id=30155
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #21 from Zebediah Figura z.figura12@gmail.com --- This should hopefully be fixed upstream as of https://source.winehq.org/git/wine.git/commitdiff/7c0f6420059974ab127ae944b55d11dd71df3b85; please retest.
https://bugs.winehq.org/show_bug.cgi?id=30155
Josh winehq@iooioio.xyz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@iooioio.xyz
-
wine-bugs＠winehq.org -
WineHQ Bugzilla