[Bug 45749] New: Visual Studio 2017 Installer fails due to node.js/ libuv listen(named pipe) error
https://bugs.winehq.org/show_bug.cgi?id=45749
Bug ID: 45749 Summary: Visual Studio 2017 Installer fails due to node.js/libuv listen(named pipe) error Product: Wine Version: 3.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: jimbo1qaz@gmail.com Distribution: ---
Created attachment 62190 --> https://bugs.winehq.org/attachment.cgi?id=62190 Visual Studio Installer logs (mostly useless)
Running Kubuntu 18.04 64-bit. I created a 32-bit .wine32 prefix, installed dotnet46 via winetricks, then the Build Tools for Visual Studio installer (https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-... ) (which shares the core with VS2017 installer. It's written in node.js and involves multiple processes communicating via what the source describes as "pipe"s).
The error is "Hub Controller process exited prematurely with exit code 1 (NodeUncaughtFatalException)."
Interestingly, the installer's source is user-readable and located in WINEPREFIX / drive_c/Program Files/Microsoft Visual Studio/Installer/resources/app/node_modules/microsoft-servicehub/host/. I was able to edit the .js files to add control flow logging:
const fs = require('fs'); function logg(val, args){ fs.writeFileSync("C:\"+process.hrtime()[1] + '_'+val, ""+args, function(err) {}); }
Installer seems to be codenamed "microsoft-servicehub". Strangely, many of the Installer files appear to test for Windows and/or *nix, despite VS being Windows-only. It also references open-source VS Code, but I was unable to find any hits when Googling for quoted strings.
----------
The error message "Hub Controller process exited prematurely with exit code" is raised from within "drive_c/Program Files/Microsoft Visual Studio/Installer/resources/app/node_modules/microsoft-servicehub/controllerConnection.js":
ControllerConnection.prototype.startController `var connectPromise` fails, calling `function (err)` to spawn a process (which crashes).
ControllerConnection.prototype.onControllerProcessExited is responsible for noticing the process has terminated, and raising the exception.
---------
The actual crash originates from "drive_c/Program Files/Microsoft Visual Studio/Installer/resources/app/node_modules/microsoft-servicehub/host/HubController.js".
HubController.js is executed by several distinct processes, and `process.pid` is the same within `function HubController()` and the global scope.
I systematically replaced all calls to `logger.error()` (info, etc.) to `logg()` (since Logger.error() called within subprocess did not show up in Visual Studio's debug logs). I get two sequentially numbered files, 1 millisecond apart:
"429988399_Successfully started server on pipe 5d74f51d8cc5d690c261c26d3e9e3408e060bd352875558b9320be9c213e0610" "430873100_Terminating controller due to some unknown error: " with contents "listen EINVAL \?\pipe\5d74f51d8cc5d690c261c26d3e9e3408e060bd352875558b9320be9c213e0610"
This error is thrown by `function retryStartServer`. `e.code` is EINVAL, while the code only handles `e.code === ec.EADDRINUSE.code`.
Looking at https://stackoverflow.com/questions/11040460/get-the-listen-einval-when-star... suggests:
EINVAL The socket is already connected.
Make sure something isn't already listening on that port.
`man errno` suggests otherwise: > EINVAL Invalid argument (POSIX.1-2001).
Adding `|| e.code === ec.EINVAL.code` and commenting `process.platform === 'win32' ||` sends the installer into an endless "kill and restart HubController" loop, which isn't what we want.
Extra notes on control flow at https://gist.github.com/jimbo1qaz/1c972422fd5c31706920b9be5c2a0f42#server
--------
The `EINVAL` error comes with a node.js stack trace: https://gist.github.com/jimbo1qaz/1c972422fd5c31706920b9be5c2a0f42#file-netw...
(The hexadecimal path originates from https://gist.github.com/jimbo1qaz/1c972422fd5c31706920b9be5c2a0f42#determini... )
https://github.com/nodejs/node/blob/68dff4a67b7222770f90fc5d9bdd884f8db4a24b... `const ex = new Error(`${syscall} ${code}${details}`);` "listen EINVAL \?\pipe\5d74f51d8cc5d690c261c26d3e9e3408e060bd352875558b9320be9c213e0610"
I think the call which failed is `listen`, which returns EINVAL for some reason.
------------
Comparing my stack trace with node.js source code (node.dll 8.9.3):
`Server.listen (net.js:1487:5)` = https://github.com/nodejs/node/blob/v8.9.3/lib/net.js#L1487 - listenInCluster(server=this, address=pipeName, port=-1, addressType=-1, backlog=backlog, fd=undefined, exclusive=options.exclusive); `listenInCluster (net.js:1392:12)` = https://github.com/nodejs/node/blob/v8.9.3/lib/net.js#L1392 - server._listen2(=address, =port, =addressType, =backlog, =fd);
Unpeeling layers of abstraction on top of Windows named pipes:
`Server.setupListenHandle [as _listen2] (net.js:1351:14)` = https://github.com/nodejs/node/blob/v8.9.3/lib/net.js#L1351
(Bullet points are not in stack trace, but I assume they executed) - `handle = new Pipe(PipeConstants.SERVER);` https://github.com/nodejs/node/blob/v8.9.3/lib/net.js#L1267 - `const { Pipe } = process.binding('pipe_wrap');` which refers to C++ code at https://github.com/nodejs/node/blob/v8.9.3/src/pipe_wrap.cc - pipes are handled by https://github.com/libuv/libuv
- `var err = this._handle.listen(backlog || 511);` is the operation which fails = https://github.com/nodejs/node/blob/8a44289089a08b7b19fa3c4651b5f1f5d1edd71b... - Routes to https://github.com/nodejs/node/blob/v8.9.3/src/pipe_wrap.cc#L154 - which calls uv_listen(). `return uv_translate_sys_error(err);` and EINVAL is located at https://github.com/libuv/libuv/blob/v1.x/src/win/error.c#L101 ... There are 7 Win32 errors all mapping to UV_EINVAL==EINVAL, but only WSAEINVAL can happen. - uv_listen() either [assert(0) and sets err=ERROR_INVALID_PARAMETER] (I hope not), calls uv_tcp_listen (I hope not) - Most likely calls uv_pipe_listen() = https://github.com/libuv/libuv/blob/1391a3d9d0996fcf1a116a9c6c58e8b1c7303193... - It has 4 return paths, only `if (!(handle->flags & UV_HANDLE_BOUND)) { return WSAEINVAL;` is happening = https://github.com/libuv/libuv/blob/1391a3d9d0996fcf1a116a9c6c58e8b1c7303193... - What initializes `handle->flags` without |=UV_HANDLE_BOUND?
ok i'm getting a headache
https://bugs.winehq.org/show_bug.cgi?id=45749
--- Comment #1 from jimbo1qaz jimbo1qaz@gmail.com --- Corrections: - `handle = new Pipe();` (PipeConstants.SERVER did not exist in node 8.9.3) - node.js ships libuv. The relevant portion is located at "deps/uv/src/win/pipe.c".
How is `handle` initialized, and why is `handle->flags` lacking |=UV_HANDLE_BOUND?
handle = new Pipe(); - uv_pipe_init()
(unsure if called) if (!isNaN(instances)) { handle.setPendingInstances(instances); - uv_pipe_pending_instances() seems unimportant
handle.bind(address="\?\pipe\5d74...", port=-1); - uv_pipe_bind() sets `handle->flags |= UV_HANDLE_BOUND;` if no errors occur (and no errors occur in net.js/createServerHandle())
rval = createServerHandle(... this._handle = rval; this._handle.onconnection = onconnection; this._handle.owner = this; var err = this._handle.listen(backlog || 511); err == EINVAL
So why isn't UV_HANDLE_BOUND set?? i don't have a clue.
https://bugs.winehq.org/show_bug.cgi?id=45749
--- Comment #2 from jimbo1qaz jimbo1qaz@gmail.com --- Also Microsoft, fix your VS2017 subprocess logging, right now they're delivered to `users/jimbo1qaz/Temp/servicehub/logs/hubController-...log` but not incorporated into the failure logs accessible through the GUI.
Also the failed installer window has no close button. I assume this is another Wine bug.
https://bugs.winehq.org/show_bug.cgi?id=45749
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de Status|UNCONFIRMED |NEW Ever confirmed|0 |1 URL| |https://visualstudio.micros | |oft.com/downloads/#build-to | |ols-for-visual-studio-2017 Keywords| |download
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- Confirming.
https://bugs.winehq.org/show_bug.cgi?id=45749
--- Comment #4 from jimbo1qaz jimbo1qaz@gmail.com --- i think trying to debug a spawned process is futile. instead let winedbg or x32dbg-in-wine launch the process itself.
Unfortunately vs_installershell.exe kept popping up a win32 dialog box error and/or argument error. inspecting servicehub.config.json reveals: ..."additionalEnvironmentVariables" : { "ELECTRON_RUN_AS_NODE": "true" }
I have constructed a method of debugging the subprocess directly via winedbg:
cd WINEPREFIX/drive_c/Program Files/Microsoft Visual Studio/Installer/resources/app ELECTRON_RUN_AS_NODE=true winedbg "C:\Program Files\Microsoft Visual Studio\Installer\vs_installershell.exe" ./node_modules/microsoft-servicehub/host/HubController.js 5d74f51d8cc5d690c261c26d3e9e3408e060bd352875558b9320be9c213e0610
Then type:
b uv_pipe_init b uv_pipe_pending_instances b uv_pipe_bind b uv_listen b uv_pipe_listen c
Sadly uv_pipe_listen cannot be breakpointed (all others work fine).
--------
uv_pipe_init get called 4 times. uv_pipe_bind gets called once. The process terminates and uv_listen is not called.
I am currently debugging uv_pipe_init via winedbg, using https://github.com/nodejs/node/blob/v8.9.3/deps/uv/src/win/pipe.c as a reference.
https://bugs.winehq.org/show_bug.cgi?id=45749
--- Comment #5 from jimbo1qaz jimbo1qaz@gmail.com --- I wiped my Javascript logging hooks completely.
When running the process in a debugger, node.js createServerHandle() seems to fail in node.js handle.bind() -> C++ something -> libuv uv_pipe_bind->uv_set_pipe_handle (I didn't debug uv_set_pipe_handle).
This winedbg command breaks on uv_set_pipe_handle:
b *0x10709ba0 c
uv_set_pipe_handle() returns nonzero, so does uv_pipe_bind and handle.bind(). If `handle.bind()` fails, https://github.com/nodejs/node/blob/v8.9.1/lib/net.js#L1292 `createServerHandle()` returns an error code and slh constructs an error at https://github.com/nodejs/node/blob/v8.9.1/lib/net.js#L1334 . Or one would think...
----------
But my stack trace indicates `createServerHandle()` succeeded and an exception was thrown later on net.js:1351 = https://gist.github.com/jimbo1qaz/1c972422fd5c31706920b9be5c2a0f42#file-netw...
This is regardless of "heavily modded installer", "deleted and redownloaded installer plus 1 logger hook", and "the latter plus launch HubController.js subprocess via unix wine", or "winedbg with breakpoint when the function fails".
-----------
Debugging Node's internal javascript: passing --inspect-brk to vs_installershell.exe then debugging via Chromium! Except breakpoints don't work, even when I symlink /C: to drive_c... Then it started working... (Sadly about:inspect "automatic connection" and NIM don't work on VS Installer)
I guess I don't need to run Chrome under Wine (https://gist.github.com/jimbo1qaz/1c972422fd5c31706920b9be5c2a0f42#chrome-un... )
--------
I managed to combine winedbg and Chrome debugging.
cd WINEPREFIX/drive_c/Program Files/Microsoft Visual Studio/Installer/resources/app ; ELECTRON_RUN_AS_NODE=true winedbg "C:\Program Files\Microsoft Visual Studio\Installer\vs_installershell.exe" --inspect-brk ./node_modules/microsoft-servicehub/host/HubController.js 5d74f51d8cc5d690c261c26d3e9e3408e060bd352875558b9320be9c213e0610
Since I can't see Node's debug "key" url in stdout, I must look at http://localhost:9229/json/list to connect to node instead.
Interesting issue within uv_pipe_bind(): - uv_set_pipe_handle returns -1 or 0xFFFFFFFF. - Yet Wine's GetLastError(); returns 0, so all callers and Node thinks nothing went wrong creating the named pipe.
if (uv_set_pipe_handle(loop, handle, handle->pipe.serv.accept_reqs[0].pipeHandle, -1, 0)) { err = GetLastError();
I am convinced that uv_set_pipe_handle() calling Wine is directly responsible for this bug.
(am I a bit obsessed with debugging this issue?)
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.
https://bugs.winehq.org/show_bug.cgi?id=45749
--- Comment #7 from Fabian Maurer dark.shadow4@web.de --- Created attachment 62200 --> https://bugs.winehq.org/attachment.cgi?id=62200 Hack to handle FileModeInformation in NtQueryInformationFile
FWIW, chromium issues can be worked around with my patches at bug 45649, bug 45650 and bug 45645 - so you don't need to disable the sandbox. But that's not very relevant for this issue, I think.
(am I a bit obsessed with debugging this issue?)
I dunno, but you did a very good job, thank you for that! It's indeed NtQueryInformationFile with NtQueryInformationFile that's missing here. I'm attaching a quick hack (on top of wine git) to work around this issue.
https://bugs.winehq.org/show_bug.cgi?id=45749
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Visual Studio 2017 |Visual Studio 2017 |Installer fails due to |Installer needs |node.js/libuv listen(named |NtQueryInformationFile to |pipe) error |handle FileModeInformation Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=45749
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |45757
https://bugs.winehq.org/show_bug.cgi?id=45749
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll
--- Comment #8 from Fabian Maurer dark.shadow4@web.de --- After applying the workaround, the installer starts, but still doesn't work. See bug 45757 for the "The installer manifest failed signature validation" issue.
https://bugs.winehq.org/show_bug.cgi?id=45749
--- Comment #9 from jimbo1qaz jimbo1qaz@gmail.com --- Fun fact: one forum user commented on my debugging process, "I'll take *Nightmare Fuel* for $2000, Alex."
Where should I report documentation issues? (Maybe you should delete `symbolfile pathname` from https://wiki.winehq.org/Wine_Developer%27s_Guide/Debugging_Wine#Directory_.2... , considering the function has been stubbed out completely. How *do* we load symbols from EXE files?)
Additionally I don't think I want to spend the effort recompiling Wine in order to debug further.
https://bugs.winehq.org/show_bug.cgi?id=45749
--- Comment #10 from Fabian Maurer dark.shadow4@web.de ---
Where should I report documentation issues?
AFAIK just in the bugtracker here should be fine. I sadly don't know much about winedbg, almost never use it. What exactly are you trying to get from the symbols?
Additionally I don't think I want to spend the effort recompiling Wine in order to debug further.
I can understand that. Although it's not that hard, when you got it to build once. Maybe we can get a fix into one of the next development releases.
https://bugs.winehq.org/show_bug.cgi?id=45749
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Keywords| |Installer
https://bugs.winehq.org/show_bug.cgi?id=45749
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Visual Studio 2017 |Multiple Node.js based |Installer needs |applications/installers |NtQueryInformationFile to |need |handle FileModeInformation |ntdll.NtQueryInformationFil | |e to handle | |'FileModeInformation' | |information class (MS | |Visual Studio 2017 | |Installer, FACEIT | |Anti-cheat client)
--- Comment #11 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming, found another app which uses Node.js and fails due to this problem.
Anti-Cheat FACEIT client: https://faceit-client.faceit.com/release/FACEIT-setup-latest.exe
Prerequisite:
* 64-bit WINEPREFIX * .NET Framework 4.5
--- snip --- $ WINEDEBUG=+seh,+relay wine ./FACEIT.exe >>log.txt 2>&1 ... 0036:Call KERNEL32.GetEnvironmentVariableW(0022d658 L"NODE_PENDING_PIPE_INSTANCES",0022de60,00007fff) ret=18004522f 0036:Ret KERNEL32.GetEnvironmentVariableW() retval=00000000 ret=18004522f ... 0036:Call KERNEL32.CreateNamedPipeW(16232620 L"\\.\pipe\faceit.client",400c0003,00000000,000000ff,00010000,00010000,00000000,00000000) ret=180140d3d 0036:Ret KERNEL32.CreateNamedPipeW() retval=0000023c ret=180140d3d 0036:Call KERNEL32.SetNamedPipeHandleState(0000023c,0023dcd0,00000000,00000000) ret=180140678 0036:Ret KERNEL32.SetNamedPipeHandleState() retval=00000001 ret=180140678 0036:Call ntdll.NtQueryInformationFile(0000023c,0023dcd8,0023dcd4,00000004,00000010) ret=18014070f 0036:Ret ntdll.NtQueryInformationFile() retval=c0000024 ret=18014070f 0036:Call KERNEL32.GetLastError() ret=180140d9c 0036:Ret KERNEL32.GetLastError() retval=00000000 ret=180140d9c 0036:Call ucrtbase._errno() ret=180132dd8 0036:Ret ucrtbase._errno() retval=0006db10 ret=180132dd8 ... 0036:Call user32.CreateWindowExW(00000000,0023c662 L"Static",04e6fe70 L"Uncaught Exception:\nTypeError: this.log is not a function\n at Server.<anonymous> (Z:\home\focht\Downloads\FACEITApp\app-1.20.0\resources\app\node_modules\node-ipc\dao\socketServer.js:292:18)\n at Server.emit (events.js:182:13)\n at emitErrorNT (net.js:1357:8)\n at process._ti"...,
50000000,00000000,00000000,00000000,00000000,000200a2,00000000,00000000,00000000) ret=7f4957120464 --- snip ---
Full message window error text:
--- snip --- Uncaught Exception: TypeError: this.log is not a function at Server.<anonymous> (Z:\home\focht\Downloads\FACEITApp\app-1.20.0\resources\app\node_modules\node-ipc\dao\socketServer.js:292:18) at Server.emit (events.js:182:13) at emitErrorNT (net.js:1357:8) at process._tickCallback(internal/process/next_tick.js:63:19) --- snip ---
--- snip --- $ tree --charset=ANSI -L 4 . |-- app-1.20.0 | |-- api-ms-win-core-console-l1-1-0.dll ... | |-- api-ms-win-crt-utility-l1-1-0.dll | |-- blink_image_resources_200_percent.pak | |-- content_resources_200_percent.pak | |-- content_shell.pak | |-- d3dcompiler_47.dll | |-- FACEIT.exe | |-- ffmpeg.dll | |-- icudtl.dat | |-- libEGL.dll | |-- libGLESv2.dll | |-- LICENSE | |-- locales | | |-- am.pak | | |-- ar.pak | | |-- bg.pak | | |-- bn.pak ... | | |-- zh-CN.pak | | `-- zh-TW.pak | |-- msvcp140.dll | |-- natives_blob.bin | |-- node.dll | |-- resources | | |-- app | | | |-- assets | | | |-- components | | | |-- config | | | |-- languages | | | |-- main.js | | | |-- node_modules | | | |-- package.json | | | `-- preload.js | | `-- electron.asar | |-- squirrel.exe | |-- SquirrelSetup.log | |-- ucrtbase.dll | |-- ui_resources_200_percent.pak | |-- v8_context_snapshot.bin | |-- vcruntime140.dll | `-- views_resources_200_percent.pak |-- FACEIT.exe |-- packages | |-- FACEITApp-1.20.0-full.nupkg | |-- RELEASES | `-- SquirrelTemp |-- SquirrelSetup.log `-- Update.exe
11 directories, 123 files --- snip ---
Applying the Fabian's patch (comment #7) fixes the problem. This might be a candidate for Wine-Staging or direct mainline.
ProtectionID scan for documentation: Node.js = 10.2
--- snip --- -=[ ProtectionID v0.6.9.0 DECEMBER]=- (c) 2003-2017 CDKiLLER & TippeX Build 24/12/17-21:05:42 Ready... Scanning -> Z:\home\focht\Downloads\FACEITApp\app-1.20.0\node.dll File Type : 64-Bit Dll (Subsystem : Win GUI / 2), Size : 18580416 (011B83C0h) Byte(s) | Machine: 0x8664 (AMD64) Compilation TimeStamp : 0x5BAD43EC -> Thu 27th Sep 2018 20:56:12 (GMT) [TimeStamp] 0x5BAD43EC -> Thu 27th Sep 2018 20:56:12 (GMT) | PE Header | - | Offset: 0x00000000:00000128 | VA: 0x00000001:80000128 | - [TimeStamp] 0xFFFFFFFF -> Sun 07th Feb 2106 06:28:15 (GMT) | Export | - | Offset: 0x00000000:00F634E4 | VA: 0x00000001:80F642E4 | - [TimeStamp] 0x5BAD43EC -> Thu 27th Sep 2018 20:56:12 (GMT) | DebugDirectory | - | Offset: 0x00000000:00EBB6C4 | VA: 0x00000001:80EBC4C4 | - [TimeStamp] 0x5BAD43EC -> Thu 27th Sep 2018 20:56:12 (GMT) | DebugDirectory | - | Offset: 0x00000000:00EBB6E0 | VA: 0x00000001:80EBC4E0 | - [TimeStamp] 0x5BAD43EC -> Thu 27th Sep 2018 20:56:12 (GMT) | DebugDirectory | - | Offset: 0x00000000:00EBB6FC | VA: 0x00000001:80EBC4FC | - -> File Appears to be Digitally Signed @ Offset 011B6800h, size : 01BC0h / 07104 byte(s) [LoadConfig] Struct determined as v8 (Expected size 232 | Actual size 248) [LoadConfig] CFG (/Guard) - Handler @ 0x1:80B001C0 [LoadConfig] CFG Table @ 0x1:80B00D40 | 0x05F3A (024378) entries [LoadConfig] CFG Flags : 0x13500 [LoadConfig] CodeIntegrity -> Flags 0x0 | Catalog 0x0 (0) | Catalog Offset 0x0 | Reserved 0x0 [LoadConfig] GuardAddressTakenIatEntryTable 0x0:00000000 | Count 0x000000000 (00) [LoadConfig] GuardLongJumpTargetTable 0x0:00000000 | Count 0x000000000 (00) [LoadConfig] HybridMetadataPointer 0x1:80B00D40 | DynamicValueRelocTable 0x0:00000000 [LoadConfig] FailFastIndirectProc 0x80AFA810:00000001 | FailFastPointer 0x80B001D0:00000001 [LoadConfig] UnknownZero1 0x0 0 [File Heuristics] -> Flag #1 : 00000100000001001101000100000100 (0x0404D104) [Entrypoint Section Entropy] : 6.39 (section #0) ".text " | Size : 0xAFDCFB (11525371) byte(s) [DllCharacteristics] -> Flag : (0x4160) -> HEVA | ASLR | DEP | CFG [SectionCount] 6 (0x6) | ImageSize 0x11CE000 (18669568) byte(s) [Export] 98% of function(s) (18191 of 18456) are in file | 0 are forwarded | 17330 code | 1126 data | 0 uninit data | 0 unknown | [VersionInfo] Company Name : Node.js [VersionInfo] Product Name : Node.js [VersionInfo] Product Version : 10.2.0 [VersionInfo] File Description : Node.js: Server-side JavaScript [VersionInfo] File Version : 10.2.0 [VersionInfo] Original FileName : node.exe [VersionInfo] Internal Name : node [VersionInfo] Legal Copyrights : Copyright Node.js contributors. MIT license. [ModuleReport] [IAT] Modules -> PSAPI.DLL | ADVAPI32.dll | IPHLPAPI.DLL | USER32.dll | USERENV.dll | WS2_32.dll | CRYPT32.dll | dbghelp.dll | MSVCP140.dll | bcrypt.dll | KERNEL32.dll | VCRUNTIME140.dll | api-ms-win-crt-runtime-l1-1-0.dll | api-ms-win-crt-stdio-l1-1-0.dll | api-ms-win-crt-heap-l1-1-0.dll | api-ms-win-crt-string-l1-1-0.dll | api-ms-win-crt-filesystem-l1-1-0.dll | api-ms-win-crt-convert-l1-1-0.dll | api-ms-win-crt-environment-l1-1-0.dll | api-ms-win-crt-math-l1-1-0.dll | api-ms-win-crt-utility-l1-1-0.dll | api-ms-win-crt-time-l1-1-0.dll | api-ms-win-crt-locale-l1-1-0.dll | WINMM.dll [Debug Info] (record 1 of 3) (file offset 0xEBB6C0) Characteristics : 0x0 | TimeDateStamp : 0x5BAD43EC (Thu 27th Sep 2018 20:56:12 (GMT)) | MajorVer : 0 / MinorVer : 0 -> (0.0) Type : 2 (0x2) -> CodeView | Size : 0x40 (64) AddressOfRawData : 0xEC9B44 | PointerToRawData : 0xEC8D44 CvSig : 0x53445352 | SigGuid D4C22F4B-9E92-4CBC-8289623B7EB2D055 Age : 0x1 (1) | Pdb : C:\projects\electron\out\R\node.dll.pdb [Debug Info] (record 2 of 3) (file offset 0xEBB6DC) Characteristics : 0x0 | TimeDateStamp : 0x5BAD43EC (Thu 27th Sep 2018 20:56:12 (GMT)) | MajorVer : 0 / MinorVer : 0 -> (0.0) Type : 12 (0xC) -> Undocumented | Size : 0x14 (20) AddressOfRawData : 0xEC9B84 | PointerToRawData : 0xEC8D84 [Debug Info] (record 3 of 3) (file offset 0xEBB6F8) Characteristics : 0x0 | TimeDateStamp : 0x5BAD43EC (Thu 27th Sep 2018 20:56:12 (GMT)) | MajorVer : 0 / MinorVer : 0 -> (0.0) Type : 13 (0xD) -> Undocumented | Size : 0x36C (876) AddressOfRawData : 0xEC9B98 | PointerToRawData : 0xEC8D98 ... [!] File appears to have no protection or is using an unknown protection - Scan Took : 3.996 Second(s) [000000BBCh (3004) tick(s)] [162 of 580 scan(s) done] --- snip ---
$ sha1sum FACEIT-setup-latest.exe 332b313b0e34a3a7398a8e9b1537399c128034f4 FACEIT-setup-latest.exe
$ du -sh FACEIT-setup-latest.exe 58M FACEIT-setup-latest.exe
$ wine --version wine-3.18
Regards
https://bugs.winehq.org/show_bug.cgi?id=45749
Mathew Hodson mathew.hodson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mathew.hodson@gmail.com
--- Comment #12 from Mathew Hodson mathew.hodson@gmail.com --- Patch was committed
https://source.winehq.org/git/wine.git/commitdiff/2adfa93a7f643341765d80af83...
https://bugs.winehq.org/show_bug.cgi?id=45749
Mathew Hodson mathew.hodson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|mathew.hodson@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=45749
--- Comment #13 from jimbo1qaz jimbo1qaz@gmail.com --- Is it normal for stubbed NtQueryInformationFile operations to cause GetLastError(); to return 0? Or should Wine be changed to make stubs set an error code?
If Windows also sets GetLastError to 0 for unrecognized NtQueryInformationFile modes, libuv may have a bug causing it to not catch unimplemented operations.
https://bugs.winehq.org/show_bug.cgi?id=45749
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |2adfa93a7f643341765d80af83c | |e99a9c6b23b72 Status|NEW |RESOLVED
--- Comment #14 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming, it works now.
--- snip --- $ WINEDEBUG=+seh,+relay wine ./FACEIT.exe >>log.txt 2>&1 ... 0043:Call KERNEL32.CreateNamedPipeW(1562fa00 L"\\.\pipe\faceit.client",400c0003,00000000,000000ff,00010000,00010000,00000000,00000000) ret=180140d3d 0043:Ret KERNEL32.CreateNamedPipeW() retval=00000384 ret=180140d3d 0043:Call KERNEL32.SetNamedPipeHandleState(00000384,0023dce0,00000000,00000000) ret=180140678 0043:Ret KERNEL32.SetNamedPipeHandleState() retval=00000001 ret=180140678 0043:Call ntdll.NtQueryInformationFile(00000384,0023dce8,0023dce4,00000004,00000010) ret=18014070f 0043:Ret ntdll.NtQueryInformationFile() retval=00000000 ret=18014070f 0043:Call KERNEL32.CreateIoCompletionPort(00000384,000000f0,15767c90,00000000) ret=180140732 0043:Ret KERNEL32.CreateIoCompletionPort() retval=000000f0 ret=180140732 0043:Call ucrtbase._dtest(0023e260) ret=180010185 0043:Ret ucrtbase._dtest() retval=ffffffff ret=180010185 0043:Call KERNEL32.ConnectNamedPipe(00000384,156f8140) ret=1801414ce 0043:Ret KERNEL32.ConnectNamedPipe() retval=00000000 ret=1801414ce 0043:Call KERNEL32.GetLastError() ret=1801414d8 0043:Ret KERNEL32.GetLastError() retval=000003e5 ret=1801414d8 0043:Call KERNEL32.CreateNamedPipeW(1562fa00 L"\\.\pipe\faceit.client",40040003,00000000,000000ff,00010000,00010000,00000000,00000000) ret=180141408 0043:Ret KERNEL32.CreateNamedPipeW() retval=000003c0 ret=180141408 0043:Call KERNEL32.SetNamedPipeHandleState(000003c0,0023e1b0,00000000,00000000) ret=180140678 0043:Ret KERNEL32.SetNamedPipeHandleState() retval=00000001 ret=180140678 0043:Call ntdll.NtQueryInformationFile(000003c0,0023e1b8,0023e1b4,00000004,00000010) ret=18014070f 0043:Ret ntdll.NtQueryInformationFile() retval=00000000 ret=18014070f 0043:Call KERNEL32.CreateIoCompletionPort(000003c0,000000f0,15767c90,00000000) ret=180140732 0043:Ret KERNEL32.CreateIoCompletionPort() retval=000000f0 ret=180140732 0043:Call KERNEL32.ConnectNamedPipe(000003c0,156f81c0) ret=1801414ce 0043:Ret KERNEL32.ConnectNamedPipe() retval=00000000 ret=1801414ce 0043:Call KERNEL32.GetLastError() ret=1801414d8 0043:Ret KERNEL32.GetLastError() retval=000003e5 ret=1801414d8 0043:Call KERNEL32.CreateNamedPipeW(1562fa00 L"\\.\pipe\faceit.client",40040003,00000000,000000ff,00010000,00010000,00000000,00000000) ret=180141408 0043:Ret KERNEL32.CreateNamedPipeW() retval=00000484 ret=180141408 0043:Call KERNEL32.SetNamedPipeHandleState(00000484,0023e1b0,00000000,00000000) ret=180140678 0043:Ret KERNEL32.SetNamedPipeHandleState() retval=00000001 ret=180140678 0043:Call ntdll.NtQueryInformationFile(00000484,0023e1b8,0023e1b4,00000004,00000010) ret=18014070f 0043:Ret ntdll.NtQueryInformationFile() retval=00000000 ret=18014070f 0043:Call KERNEL32.CreateIoCompletionPort(00000484,000000f0,15767c90,00000000) ret=180140732 0043:Ret KERNEL32.CreateIoCompletionPort() retval=000000f0 ret=180140732 0043:Call KERNEL32.ConnectNamedPipe(00000484,156f8240) ret=1801414ce 0043:Ret KERNEL32.ConnectNamedPipe() retval=00000000 ret=1801414ce 0043:Call KERNEL32.GetLastError() ret=1801414d8 0043:Ret KERNEL32.GetLastError() retval=000003e5 ret=1801414d8 0043:Call KERNEL32.CreateNamedPipeW(1562fa00 L"\\.\pipe\faceit.client",40040003,00000000,000000ff,00010000,00010000,00000000,00000000) ret=180141408 0043:Ret KERNEL32.CreateNamedPipeW() retval=00000488 ret=180141408 0043:Call KERNEL32.SetNamedPipeHandleState(00000488,0023e1b0,00000000,00000000) ret=180140678 0043:Ret KERNEL32.SetNamedPipeHandleState() retval=00000001 ret=180140678 0043:Call ntdll.NtQueryInformationFile(00000488,0023e1b8,0023e1b4,00000004,00000010) ret=18014070f 0043:Ret ntdll.NtQueryInformationFile() retval=00000000 ret=18014070f 0043:Call KERNEL32.CreateIoCompletionPort(00000488,000000f0,15767c90,00000000) ret=180140732 0043:Ret KERNEL32.CreateIoCompletionPort() retval=000000f0 ret=180140732 0043:Call KERNEL32.ConnectNamedPipe(00000488,156f82c0) ret=1801414ce 0043:Ret KERNEL32.ConnectNamedPipe() retval=00000000 ret=1801414ce 0043:Call KERNEL32.GetLastError() ret=1801414d8 0043:Ret KERNEL32.GetLastError() retval=000003e5 ret=1801414d8 ... 0043:Call KERNEL32.PostQueuedCompletionStatus(000000f0,00000000,00000000,005a6d68) ret=18014b70a 0043:Ret KERNEL32.PostQueuedCompletionStatus() retval=00000001 ret=18014b70a ... --- snip ---
Regards
https://bugs.winehq.org/show_bug.cgi?id=45749
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.20.
https://bugs.winehq.org/show_bug.cgi?id=45749
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|https://visualstudio.micros |https://web.archive.org/web |oft.com/downloads/#build-to |/20190108140807/https://dow |ols-for-visual-studio-2017 |nload.visualstudio.microsof | |t.com/download/pr/a46d2db7- | |bd7b-43ee-bd7b-12624297e4ec | |/11b9c9bd44ec2b475f6da3d180 | |2b3d00/vs_buildtools.exe
-
wine-bugs＠winehq.org -
WineHQ Bugzilla