http://bugs.winehq.org/show_bug.cgi?id=12332
Summary: driver dev kit won't install Product: Wine Version: 0.9.58. Platform: PC-x86-64 URL: http://download.microsoft.com/download/9/0/f/90f019ac- 8243-48d3-91cf-81fc4093ecfd/1830_usa_ddk.iso OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: setupapi AssignedTo: wine-bugs@winehq.org ReportedBy: htl10@users.sourceforge.net
This seems to be a problem with setupapi rather than msi... in an case, I am just after the documentations and the examples, so I just like it to unpack nicely, the result doesn't need to be functional...
http://bugs.winehq.org/show_bug.cgi?id=12332
--- Comment #1 from Hin-Tak Leung htl10@users.sourceforge.net 2008-04-03 12:45:11 --- Created an attachment (id=11834) --> (http://bugs.winehq.org/attachment.cgi?id=11834) +setupapi,+relay log, gz'ed
+setupapi,+relay log, gz'ed
http://bugs.winehq.org/show_bug.cgi?id=12332
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, Installer
--- Comment #2 from Austin English austinenglish@gmail.com 2008-10-17 16:01:38 --- Is this still a problem in current (1.1.6 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=12332
--- Comment #3 from Hin-Tak Leung htl10@users.sourceforge.net 2008-10-18 05:19:01 --- I'll try and report back... since the doc kit still doesn't run, this is unlikely to run either.
http://bugs.winehq.org/show_bug.cgi?id=12332
--- Comment #4 from Jerome Leclanche adys.wh@gmail.com 2009-12-02 17:26:01 --- Created an attachment (id=25051) --> (http://bugs.winehq.org/attachment.cgi?id=25051) Backtrace
Crashes during install now.
http://bugs.winehq.org/show_bug.cgi?id=12332
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com 2009-12-02 17:29:36 --- (In reply to comment #4)
Created an attachment (id=25051)
--> (http://bugs.winehq.org/attachment.cgi?id=25051) [details]
Backtrace
Crashes during install now.
Please attach log with debug symbols.
http://bugs.winehq.org/show_bug.cgi?id=12332
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #6 from Austin English austinenglish@gmail.com 2011-05-08 18:43:16 CDT --- Still in wine-1.3.18-170-gfa2e4bb, attaching logs.
http://bugs.winehq.org/show_bug.cgi?id=12332
--- Comment #7 from Austin English austinenglish@gmail.com 2011-05-08 18:43:44 CDT --- Created an attachment (id=34555) --> (http://bugs.winehq.org/attachment.cgi?id=34555) +setupapi log / backtrace
http://bugs.winehq.org/show_bug.cgi?id=12332
Frédéric Delanoy frederic.delanoy@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |frederic.delanoy@gmail.com
--- Comment #8 from Frédéric Delanoy frederic.delanoy@gmail.com 2013-07-11 07:12:35 CDT --- Still in wine-1.6-rc4-99-g94c7806
http://bugs.winehq.org/show_bug.cgi?id=12332
Jeff Muizelaar jrmuizel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jrmuizel@gmail.com
--- Comment #9 from Jeff Muizelaar jrmuizel@gmail.com --- It's crashing in SetupCloseFileQueue. The handle that it passes to SetupCloseFileQueue doesn't match the handle it gets back from SetupOpenFileQueue. This mismatch seems to happen even on real Windows so the real SetupCloseFileQueue must be doing a check of some sort to avoid crashing.
However, an even larger problem than the crash is that the extraction doesn't work at all. If you look at the setupapi log there are lines like:
fixme:setupapi:extract_cabinet_file awful hack: extracting cabinet "C:\WINDDK\3790.1830\CMNINCS.cab" trace:setupapi:SetupDefaultQueueCallbackA end copy "C:\WINDDK\3790.1830\CMNINCS_FILE_131" -> "C:\WINDDK\3790.1830\\inc\crt\ciso646" trace:setupapi:SetupDefaultQueueCallbackA start copy "C:\WINDDK\3790.1830\CMNINCS_FILE_132" -> "C:\WINDDK\3790.1830\\inc\crt\climits" trace:setupapi:SetupCommitFileQueueW copying file L"C:\WINDDK\3790.1830\CMNINCS_FILE_132" -> L"C:\WINDDK\3790.1830\\inc\crt\climits" trace:setupapi:do_file_copyW copy L"C:\WINDDK\3790.1830\CMNINCS_FILE_132" to L"C:\WINDDK\3790.1830\\inc\crt\climits" style 0x4 trace:setupapi:do_file_copyW SizeTarget 0 ... SizeSource 0 trace:setupapi:do_file_copyW Did copy... rc was 0
But there is no C:\WINDDK\3790.1830\CMNINCS.cab to extract from and thus no C:\WINDDK\3790.1830\CMNINCS_FILE_132 to copy to C:\WINDDK\3790.1830\\inc\crt\climits
Basiclly what seems to be happening is a call to SetupInstallFilesFromInfSectionA and with a SourceRootPath of "C:\WINDDK\3790.1830\" this confuses the wine setupapi.dll but the windows setupapi.dll manages to get the correct source for the files.
https://bugs.winehq.org/show_bug.cgi?id=12332
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |corneliumilos@yahoo.com
--- Comment #10 from Anastasius Focht focht@gmx.net --- *** Bug 29989 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=12332
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Summary|driver dev kit won't |Microsoft Windows Server |install |2003 DDK SP1 installer | |crashes | |('setupapi.SetupCloseFileQu | |eue' should do proper | |handle validation before | |accessing members) Severity|enhancement |normal
--- Comment #11 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming.
Jeff (comment #9) already correctly analysed the issue - 'SetupCloseFileQueue' gets the wrong handle.
It seems the handle is actually the context returned from 'SetupInitDefaultQueueCallbackEx'.
Relevant part of trace log:
--- snip --- $ WINEDEBUG=+tid,+seh,+relay,+setupapi wine ./Kitsetup.exe >>~/log.txt 2>&1 ... 002c:Call setupapi.SetupOpenFileQueue() ret=010088b6 ... 002c:Ret setupapi.SetupOpenFileQueue() retval=00171708 ret=010088b6 002c:Call setupapi.SetupInitDefaultQueueCallbackEx(000100d4,000100d4,00000401,00000000,00000000) ret=010088f7 ... 002c:Ret setupapi.SetupInitDefaultQueueCallbackEx() retval=006a1450 ret=010088f7 002c:Call setupapi.SetupInstallFilesFromInfSectionA(00662c90,00000000,00171708,01002044 "DefaultInstall",00676af8 "C:\WINDDK\3790.1830",00000004) ret=0100892d ... 002c:Ret setupapi.SetupInstallFilesFromInfSectionA() retval=00000001 ret=0100892d 002c:Call setupapi.SetupCommitFileQueueA(00000000,00171708,01007a1d,006a1450) ret=0100895f 002c:Call setupapi.SetupDefaultQueueCallbackA(006a1450,00000001,00000000,00000000) ret=01007bbc 002c:trace:setupapi:SetupDefaultQueueCallbackA start queue 002c:Ret setupapi.SetupDefaultQueueCallbackA() retval=00000001 ret=01007bbc 002c:Call setupapi.SetupDefaultQueueCallbackA(006a1450,00000003,00000000,00000106) ret=01007bbc 002c:trace:setupapi:SetupDefaultQueueCallbackA start subqueue 0 count 262 002c:Ret setupapi.SetupDefaultQueueCallbackA() retval=00000001 ret=01007bbc ... 002c:Ret setupapi.SetupCommitFileQueueA() retval=00000001 ret=0100895f 002c:Call setupapi.SetupInstallFromInfSectionA(00000000,00662c90,01002044 "DefaultInstall",00000004,00000000,00b5e4b8 "Z:\home\focht\iso\Common",00000000,00000000,00000000,00000000,00000000) ret=010089a5 ... 002c:Ret setupapi.SetupInstallFromInfSectionA() retval=00000001 ret=010089a5 002c:Call setupapi.SetupCloseFileQueue(006a1450) ret=01008a50 002c:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7e536585 ip=7e536585 tid=002c 002c:trace:seh:raise_exception info[0]=00000000 002c:trace:seh:raise_exception info[1]=4351505b 002c:trace:seh:raise_exception eax=43515053 ebx=00000000 ecx=00b5db20 edx=00000004 esi=00b5db58 edi=00b5db24 002c:trace:seh:raise_exception ebp=00b5dad8 esp=00b5da90 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206 002c:trace:seh:call_stack_handlers calling handler at 0x7bcb50ab code=c0000005 flags=0 002c:Call KERNEL32.UnhandledExceptionFilter(00b5d574) ret=7bcb50e5 wine: Unhandled page fault on read access to 0x4351505b at address 0x7e536585 (thread 002c), starting debugger... ... --- snip ---
SetupOpenFileQueue -> 00171708 SetupInitDefaultQueueCallbackEx -> 006a1450 SetupCloseFileQueue -> 006a1450
Seems a stupid mistake on behalf of Microsoft. There is no other code path in the installer that can produce a different result.
It's not uncommon that internal data structures which are opaque to the outside (handle), contain some "magic id" member to uniquely identify/distinguish them from other structures.
https://source.winehq.org/git/wine.git/blob/dcab5fe61bed87b291901ceff686894a...
--- snip --- 39 /* context structure for the default queue callback */ 40 struct default_callback_context 41 { 42 DWORD magic; 43 HWND owner; 44 DWORD unk1[4]; 45 DWORD_PTR unk2[7]; 46 HWND progress; 47 UINT message; 48 DWORD_PTR unk3[5]; 49 }; ... 1484 PVOID WINAPI SetupInitDefaultQueueCallbackEx( HWND owner, HWND progress, UINT msg, 1485 DWORD reserved1, PVOID reserved2 ) 1486 { 1487 struct default_callback_context *context; 1488 1489 if ((context = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*context) ))) 1490 { 1491 context->magic = 0x43515053; /* "SPQC" */ 1492 context->owner = owner; 1493 context->progress = progress; 1494 context->message = msg; 1495 } 1496 return context; 1497 } --- snip ---
Why not doing the same for 'struct file_queue' to detect such mishap?
https://source.winehq.org/git/wine.git/blob/dcab5fe61bed87b291901ceff686894a...
--- snip --- 71 struct file_queue 72 { 73 struct file_op_queue copy_queue; 74 struct file_op_queue delete_queue; 75 struct file_op_queue rename_queue; 76 DWORD flags; 77 };
--- snip ---
If the passed handle is detected as invalid (magic not found) it should error out without further operation.
$ sha1sum 1830_usa_ddk.iso 0d2154d88a5ee252cc908630c77863bb42777387 1830_usa_ddk.iso
$ du -sh 1830_usa_ddk.iso 231M 1830_usa_ddk.iso
$ wine --version wine-1.8-rc2
Regards
https://bugs.winehq.org/show_bug.cgi?id=12332
--- Comment #12 from Nikolay Sivov bunglehead@gmail.com --- Maybe we can do the same, yes. But just to clarify - it's not a step towards compatible structure layout, Windows doesn't start this opaque structure with a magic, and SetupCloseFileQueue() can survive any input according to my testing.
https://bugs.winehq.org/show_bug.cgi?id=12332
--- Comment #13 from Anastasius Focht focht@gmx.net --- Hello Nikolay,
--- quote --- But just to clarify - it's not a step towards compatible structure layout, Windows doesn't start this opaque structure with a magic, and SetupCloseFileQueue() can survive any input according to my testing. --- quote ---
well, there is no need to be compatible when no apps depend on it. Using a magic is certainly a better way than protecting member accesses using SEH.
Regards
https://bugs.winehq.org/show_bug.cgi?id=12332
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |47107
https://bugs.winehq.org/show_bug.cgi?id=12332
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com Fixed by SHA1| |c65d98065c0038e0919f40bec4a | |9dc978fb2ade9 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #14 from Zebediah Figura z.figura12@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commitdiff/c65d98065c0038e0919f40bec4a9dc978fb2ade9.
https://bugs.winehq.org/show_bug.cgi?id=12332
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.8.
https://bugs.winehq.org/show_bug.cgi?id=12332
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.0.x
https://bugs.winehq.org/show_bug.cgi?id=12332
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|4.0.x |---
--- Comment #16 from Michael Stefaniuc mstefani@winehq.org --- Removing the 4.0.x milestone from bug fixes included in 4.0.3.