[Bug 30155] New: secdrv.sys from SafeDisc v2.05.030 does not work
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(a)winehq.org ReportedBy: stefan(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #1 from Stefan Dösinger <stefan(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #2 from Stefan Dösinger <stefan(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|ntoskrnl |-unknown Version|unspecified |1.4 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 Julian Rüger <jr98(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98(a)gmx.net -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net --- Comment #3 from Anastasius Focht <focht(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #4 from Stefan Dösinger <stefan(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #5 from Stefan Dösinger <stefan(a)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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 Anastasius Focht <focht(a)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(a)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 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 Charles Davis <cdavis(a)mymail.mines.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cdavis(a)mymail.mines.edu -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 Johan Gardhage <johan.gardhage(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johan.gardhage(a)gmail.com -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 Axper Jan <tdsbug(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tdsbug(a)gmail.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #7 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, revisiting, obviously still present. $ wine --version wine-1.7.26-23-g618f4f2 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #8 from Anastasius Focht <focht(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #9 from Anastasius Focht <focht(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Olivier Diotte <olivier(a)diotte.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |olivier(a)diotte.ca -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Stefan Dösinger <stefandoesinger(a)gmx.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger(a)gmx.at -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imwellcushtymelike(a)gmail.co | |m --- Comment #10 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- No change in Wine-staging 1.9.12 (unless there's something new). Installer exits silently. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Josh Holland <anowlcalledjosh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |anowlcalledjosh(a)gmail.com -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #11 from Fabian Maurer <dark.shadow4(a)web.de> --- Does the error still exist in wine 3.4? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #12 from Anastasius Focht <focht(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #13 from Charles Davis <cdavis5x(a)gmail.com> --- Created attachment 65976 --> https://bugs.winehq.org/attachment.cgi?id=65976 ntoskrnl: Return driver dispatch result to caller. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #14 from Charles Davis <cdavis5x(a)gmail.com> --- Created attachment 65977 --> https://bugs.winehq.org/attachment.cgi?id=65977 ntoskrnl: Always copy the buffer for non-METHOD_BUFFERED ioctls. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #15 from Charles Davis <cdavis5x(a)gmail.com> --- Created attachment 65978 --> https://bugs.winehq.org/attachment.cgi?id=65978 server: Delay completing a synchronous IRP. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #16 from Charles Davis <cdavis5x(a)gmail.com> --- Created attachment 65979 --> https://bugs.winehq.org/attachment.cgi?id=65979 server: Return the driver's 'Information' from ioctl. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #17 from Charles Davis <cdavis5x(a)gmail.com> --- These four patches should accommodate the broken behavior of SafeDisc here. With these, I was actually able to install RA2! -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair(a)hotmail.com Keywords| |patch -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Alistair Leslie-Hughes <leslie_alistair(a)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 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 --- Comment #18 from Fabian Maurer <dark.shadow4(a)web.de> --- *** Bug 44766 has been marked as a duplicate of this bug. *** -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |NEW --- Comment #19 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- The staging patchset has been disabled for a while, removing STAGED status. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Linards <linards.liepins(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |linards.liepins(a)gmail.com --- Comment #20 from Linards <linards.liepins(a)gmail.com> --- Is this issue still present? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #21 from Zebediah Figura <z.figura12(a)gmail.com> --- This should hopefully be fixed upstream as of <https://source.winehq.org/git/wine.git/commitdiff/7c0f6420059974ab127ae944b5...>; please retest. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=30155 Josh <winehq(a)iooioio.xyz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq(a)iooioio.xyz -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #22 from joaopa <jeremielapuree(a)yahoo.fr> --- Does the bug sill occur with wine-10.18? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 Gijs Vermeulen <gijsvrm@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |7c0f6420059974ab127ae944b55 | |d11dd71df3b85 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #23 from Gijs Vermeulen <gijsvrm@gmail.com> --- Since there hasn't been a response, assuming fixed by 7c0f6420059974ab127ae944b55d11dd71df3b85. If anyone can still reproduce, please reopen. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=30155 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #24 from Alexandre Julliard <julliard@winehq.org> --- Closing bugs fixed in 11.17. -- 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.
participants (3)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla
-
WineHQ Bugzilla