[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(a)winehq.org Reporter: jimbo1qaz(a)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/lib/net.js#L1348` - 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 -- 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=45749 --- Comment #1 from jimbo1qaz <jimbo1qaz(a)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. -- 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=45749 --- Comment #2 from jimbo1qaz <jimbo1qaz(a)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. -- 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=45749 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)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(a)web.de> --- Confirming. -- 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=45749 --- Comment #4 from jimbo1qaz <jimbo1qaz(a)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. -- 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=45749 --- Comment #5 from jimbo1qaz <jimbo1qaz(a)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?) -- 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=45749 --- Comment #6 from jimbo1qaz <jimbo1qaz(a)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(a)Concurrency@@YAXI(a)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. -- 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=45749 --- Comment #7 from Fabian Maurer <dark.shadow4(a)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. -- 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=45749 Fabian Maurer <dark.shadow4(a)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 -- 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=45749 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |45757 -- 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=45749 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |ntdll --- Comment #8 from Fabian Maurer <dark.shadow4(a)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. -- 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=45749 --- Comment #9 from jimbo1qaz <jimbo1qaz(a)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. -- 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=45749 --- Comment #10 from Fabian Maurer <dark.shadow4(a)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. -- 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=45749 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net Keywords| |Installer -- 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=45749 Anastasius Focht <focht(a)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(a)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 -- 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=45749 Mathew Hodson <mathew.hodson(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathew.hodson(a)gmail.com --- Comment #12 from Mathew Hodson <mathew.hodson(a)gmail.com> --- Patch was committed https://source.winehq.org/git/wine.git/commitdiff/2adfa93a7f643341765d80af83... -- 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=45749 Mathew Hodson <mathew.hodson(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|mathew.hodson(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=45749 --- Comment #13 from jimbo1qaz <jimbo1qaz(a)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. -- 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=45749 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |2adfa93a7f643341765d80af83c | |e99a9c6b23b72 Status|NEW |RESOLVED --- Comment #14 from Anastasius Focht <focht(a)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 -- 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=45749 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #15 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 3.20. -- 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=45749 Anastasius Focht <focht(a)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 -- 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 (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla