https://bugs.winehq.org/show_bug.cgi?id=45749
--- Comment #6 from jimbo1qaz jimbo1qaz@gmail.com --- (Unrelated tangent: I tried debugging vs_installershell.exe in x64dbg x32dbg.exe, but it crashes on Wine 3.14 (Unhandled exception: unimplemented function msvcr120.dll.?wait@Concurrency@@YAXI@Z called in 32-bit code (0x7b43d3bc).). Overriding with real msvcr120.dll fixes the crash.
Then when I open vs_installershell.exe, it crashes with a near-null pointer exception (which you're not supposed to report while using DLL overrides). Haven't verified it doesn't crash on Windows.
-----------
I decided it would be less unpleasant (compared to looking at asm) to log all Wine system calls while looking at libuv uv_set_pipe_handle() source code. I should've done this from the very beginning.
ELECTRON_RUN_AS_NODE=true WINEDEBUG=+relay winedbg "C:\Program Files\Microsoft Visual Studio\Installer\vs_installershell.exe" ./node_modules/microsoft-servicehub/host/HubController.js 5d74f51d8cc5d690c261c26d3e9e3408e060bd352875558b9320be9c213e0610 2> ~/relay
System calls relevant to uv_set_pipe_handle():
0081:Call KERNEL32.SetNamedPipeHandleState(00000118,0033eb50,00000000,00000000) ret=10709bec 0081:Ret KERNEL32.SetNamedPipeHandleState() retval=00000001 ret=10709bec
if (!SetNamedPipeHandleState(pipeHandle, &mode, NULL, NULL)) { if not 1: something went wrong. so nothing went wrong.
--------
0081:Call ntdll.NtQueryInformationFile(00000118,0033eb40,0033eb4c,00000004,00000010) ret=10709c62 0081:Ret ntdll.NtQueryInformationFile() retval=c0000024 ret=10709c62
nt_status = pNtQueryInformationFile(pipeHandle, &io_status, &mode_info, sizeof(mode_info), FileModeInformation); if (nt_status != STATUS_SUCCESS) { return -1; }
Is the absence of SetLastError a bug on libuv's part, or does it expect Wine's API to set said error flag? Either way uv_set_pipe_handle returns 0 to uv_pipe_bind to uv_bind to "net.js" handle.bind(address, port) to createServerHandle() despite failing.
---------
Issue: NtQueryInformationFile is returning STATUS_OBJECT_TYPE_MISMATCH on what I assume is a named pipe.
0xC0000024 STATUS_OBJECT_TYPE_MISMATCH {Wrong Type} There is a mismatch between the type of object that is required by the requested operation and the type of object that is specified in the request.
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/... https://source.winehq.org/WineAPI/NtQueryInformationFile.html https://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented... (presses Ctrl+U) There's something so anachronistic about the combination of Cloudflare scripts with the retro aesthetic of chm2web copyright 2002-2005...
ELECTRON_RUN_AS_NODE=true winedbg "C:\Program Files\Microsoft Visual Studio\Installer\vs_installershell.exe" ./node_modules/microsoft-servicehub/host/HubController.js 5d74f51d8cc5d690c261c26d3e9e3408e060bd352875558b9320be9c213e0610
b uv_pipe_bind c b NtQueryInformationFile c
Don't run `next`, you'll get: 00e8:fixme:winedbg:be_i386_is_jump unknown 8b (wait 1 second) 00e8:fixme:winedbg:be_i386_is_jump unknown 55 (wait 1 second) and an endless flood of these messages.
libuv calls NtQueryInformationFile with FILE_INFORMATION_CLASS = FileModeInformation.
I couldn't view source for ntdll, even after installing `sudo apt install wine-devel-dbg`. I think NtQueryInformationFile *jumps to* (not calls) server_get_file_info, passing in `FileModeInformation`. Afterwards, server_get_file_info *jumps to* a hardcoded return EIP.
The call to `io->u.Status = wine_server_call( req );` (https://github.com/wine-mirror/wine/blob/master/dlls/ntdll/file.c#L209 ) leaves EAX with a value of c0000024, which is returned from wine_server_call and from NtQueryInformationFile.
FileModeInformation barely appears in the Wine source code, I suspect it's unimplemented (which explains "There is a mismatch between the type of object that is required by the requested operation and the type of object that is specified in the request"). But libuv uses FileModeInformation and expects a successful response.