`AttachConsole failed with error 6` Renderer Error

[AaronBeaudoin]

Every time I run electron-webpack dev is get the following renderer error: AttachConsole failed with error 6: The handle is invalid.

Nothing I've tried has been able to remove this warning, and it seems to be resulting in another warning later when I close my app: CtrlC(): GenerateConsoleCtrlEvent failed with error 6: The handle is invalid. Again, both of these warning are marked as being from the renderer process.

I'm on Windows 10 using Node 8.11.1 and electron-webpack 2.7.4.

Any help would be much appreciated.

[loopmode]

I usually just ignore those :) looking forward for hints and solutions tho!

[Suniron]

@AaronBeaudoin I have the same issue 🙁. Did you solved it?

[b-zurg]

I actually don't think this is a huge issue but it is certainly is annoying. I couldn't find much about the error when digging through Any help would be appreciated but in the meantime it's a working dev environment.

[loopmode]

Does somebody on Mac or Linux have this issue, or is it a Windows thing?

[loopmode]

I ask because I suspect this is related to runnerw.exe which is used: https://github.com/electron-userland/electron-webpack/blob/master/packages/electron-webpack/src/dev/ChildProcessManager.ts We have this other issue of Ctrl+c not killing the webpack process correctly, which is definitely because of runnerw.exe. And, I tried once to simply not use runnerw.exe despite of being on Windows, and it actually still worked fine for me, plus Ctrl+C killed all processes.

I'm curious to know if it helps with this warning as well. I'll try and report if i find the time, feel free to try as well. Just edit the file in node_modules and remove the special treatment for Windows.

[Suniron]

Yes it's only on Windows for me. The same project has no error on Ubuntu or Raspbian

[b-zurg]

I just tried on mac also. Totes a Windows thing.

[loopmode]

Well then, as mentioned in https://github.com/electron-userland/electron-webpack/issues/249#issuecomment-509558755 we might provide an opt-out of runnerw.exe. while it would be elegant to do it via config, it would be much much simpler via env var. And it would solve the zombie child process problem. However, I'm not sure what we would lose, apparently something about low level signal propagation. In my quick test, everything seemed to work fine but I think we should do some more testing. Since I'm currently actively working with electron-webpack again, I'll give this some time tomorrow. Would be awesome if you guys could join in and also try it out.

(On the other hand, there's not much to lose if it's just an opt-out).

[loopmode]

As suspected, not using runnerw.exe on windows helps.

[loopmode]

If you use cmd.exe, this problem doesn't occur. It only happens when you use e.g. git bash.

It seems that when electron-webpack checks for win32 platform, it assumes cmd.exe and launches child processes via runnerw.exe. This is good for cmd.exe, however I would bet that most or at least many developers on windows use git bash instead. Still checking if we should control this behaviour via env variable (e.g. ELECTRON_WEBPACK_USE_RUNNERW or ELECTRON_WEBPACK_SKIP_RUNNERW). It would be better to detect that we are indeed inside cmd.exe instance.

[Suniron]

I have tried with cmd.exe and the problem is here also.. Same with Powershell, Cmder. I must launch my command yarn dev in Admin mode because i'm on profesional computer..

[loopmode]

Hm okay then. Hmm. Then I cannot be sure that skipping runnerw.exe will help without somebody cross-checking, seems my local situation is not reliable enough. @Suniron since you're already taking time for this.. could you maybe check? See my link to a comment in #249 , there is a isWin check in DevRunner. You could just disable it inside installed node_modules and re-test.

[b-zurg]

I just tried this out. In ChildProcessManager.js in my node_modules I changed this function

function run(program, args, options) {
  const isWin = process.platform === "win32";
  return (0, _child_process().spawn)(isWin ? path.join(__dirname, "../../vendor/runnerw.exe") : program, isWin ? [program].concat(args) : args, options);
}

to this

function run(program, args, options) {
  const isWin = process.platform === "win32";
  return (0, _child_process().spawn)(program, isWin ? [program].concat(args) : args, options);
}

and the message

┏ Renderer -------------------

  AttachConsole failed with error 6: The handle is invalid.

┗ ----------------------------

was gone. But instead the renderer failed to compile. This is on running electron-webpack dev

┏ Renderer -------------------

  i ｢wdm｣: Failed to compile.

┗ ----------------------------

The main bundle compiled fine funnily enough. I'm using git bash as a side-note.

[loopmode]

When I tried it, I completely removed the isWin: return (0, _child_process().spawn)(program, args, options); And both main and renderer seemed fine.

[obermillerk]

Also having this issue. Didn't think much of it, untli this morning when I was noticing some weird lag on my computer. Checked my task manager and there were about 2 dozen if not more rogue nodejs processes that I have since confirmed are spawned by using electronwebpack dev but not killed with the electron app or a kill signal.

I'm on Windows 10 and have been using PowerShell, but I just tried in CMD and had the same issue. @loopmode's change fixes the issue, but I'm hoping for some official resolution to this soon since I hate modifying flies in node_modules...

[msemtd]

I keep revisiting this problem to see if anyone has a fix - most recently I've been trying to add emscripten WebAssembly code to an electron-webpack app and the stderr and stdout streams just plain do not work which makes this problem look like the culprit. I can't be sure because I'm not smart enough to debug this stuff!

[loopmode]

Hi @msemtd - well you might have the perfect test case there, since you're working with the stderr and stdout streams explicitly. And, since you're working with WebAssembly, you're implicitly smart enough to try it out ;)

Could you please take a few minutes and change one line in your installed node_modules?

In the file node_modules/electron-webpack/out/dev/ChildProcessManager.js, find this line:

const isWin = process.platform === "win32";

and simply replace it with:

const isWin = false;

Then try again. Does it help? If so, we might simply go forward and drop that ugly windows workaround using runnerw.exe. The sole purpose of that thing is to make streams work on windows.. Or at least we actually really go for a simple env flag to disable it, as proposed elsewhere (e.g. ELECTRON_WEBPACK_SKIP_RUNNERW)

[msemtd]

...and simply replace it with:

const isWin = false;

Then try again. Does it help?

Sorry for the delay, yes, it does resolve the problem! [edited]

[mia1024]

I had the same problem and can confirm that changing isWin to false solves the issue. However, when I tried to ctrl-c out of the process, the renderer process asks Terminate batch job (Y/N)? instead, which I had no way to respond. After a while the process seemed to have exited due to timeout.

[shadrachtuck]

I've had this issue as well on my windows machine. I've tried the win32 = false trick which removes the error. Unfortunately, the app doesn't load and the terminal just immediately says, "Done in s" as if I had pressed control C. Let me know if anyone has a solution. Works fine on my mac machine. Another reason for me to want to throw this computer in the garbage lol.

[loopmode]

Heh, maybe we should just spend some time for a proper docker-based development setup and use that on Windows :)

[msemtd]

Is there a release on the way that incorporates the fix?

[appurist]

I'm having this problem (today). I'm not sure why the problem was closed without any resolution (other than hacking the project or forking it).

I think it eventually times out and exits, so if you're patient it's not a problem, but it certainly slows down my development edit-build-test cycle.

[einarpersson]

Same here today! Windows 10. But after 30 sec the app started as usual. But it felt a bit sketchy

[shadrachtuck]

This issue shouldn't be closed. I haven't gotten to run my application on my Windows machine for months because of this.

[loopmode]

Glad to reopen the issue guys, but it still needs somebody that tackles and solves the problem :)

[msemtd]

Is it still waiting on #249 being resolved?

[Ga-Lin]

Try this one: In the file node_modules/electron-webpack/out/dev/ChildProcessManager.js, find this line const isWin = process.platform === "win32";, change win32 to win64 may help. Perhaps it's not compatible with your 64 bit system.

[loopmode]

@Ga-Lin the value is always win32 for Windows regardless of the actual architecture, see https://nodejs.org/api/process.html#process_process_platform

[Ga-Lin]

@loopmode well, you are right, I did't read that carefully before, but something interesting happens today, when I run my application again without any changes(still use win32 and don't change isWin), the issue doesn't occur any more... I just reboot my computer