<Bas> jimm: This should really be made easier, it's a huge barrier for me for keeping e10s on (i.e. I strictly run with it switched off now unless I'm debugging an e10s bug) <jimm> Bas: what would you like to see added? <Bas> jimm: I just want to startup visual studio, and I want that visual studio to end up attached to the parent and child process :p <Bas> jimm: i.e., as a non-e10s person I should be oblivious to that we're using e10s or not when debugging things :) <jimm> Bas: you're basically asking if visual studio supports auto attaching to child processes spawned by the parent. <Bas> jimm: It does, afaik. <jimm> Bas: well, I wonder why it doesn't work for us? <jimm> I guess we should file a bug on that. and here we are.

(In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #1) > https://visualstudiogallery.msdn.microsoft.com/a1141bff-463f-465f-9b6d- > d29b7b503d7a I've found this works except with low rights content processes, anyone else running into trouble as well?

(In reply to Jim Mathies [:jimm] from comment #2) > (In reply to Ben Turner [:bent] (use the needinfo flag!) from comment #1) > > https://visualstudiogallery.msdn.microsoft.com/a1141bff-463f-465f-9b6d- > > d29b7b503d7a > > I've found this works except with low rights content processes, anyone else > running into trouble as well? Hmm, doesn't have anything to do with low rights I guess. The addin only seems to attach to one plugin-container, and ignores the rest.

I actually have trouble getting it to work at all. But all the comments on the blog seem to say it works... I don't know.

I just hacked this up; it *almost* works, but the flow is a little annoying. The child process launches, but: - I get the JIT Debug dialog box ("close instance", "check for solution", "debug"). Would be nice for this to automatically Debug. - If you hit Debug, you get prompted for an instance of VS; the one that's already debugging [usually] doesn't show up. - 1) You can then go to the running VS and do "Attach to Process", and hit No in the dialog, then hit "Continue" in the dialog saying that plugin-container hit a breakpoint - 2) You can then launch a new instance of VS to debug, and hit Continue in the new debugger that launches If you do 1, then you're debugging both processes in the same VS, which is nice; you can switch between them, set breakpoints in any etc. But having to go through the "Debug" -> "Attach to Process" -> "No" -> select process and hit Continue. Once you do this, things should be working, but assertions are hit because the pid is not what we expect -- the pid we got from launching the child process is the vsjitdebugger pid, not the plugin-container pid. Another approach that might work better would be to add a "-waitfordebugger" option to plugin-container, which would do something like: if (bWaitForDebugger) { while (!::IsDebuggerPresent()) { Sleep(100); } } at the very start of content_process_main. Then, instead of using vsjitdebugger.exe as a wrapper, we'd launch it immediately after launching the child process using "vsjitdebugger.exe -p <pid>". It wouldn't catch static initializers, but it would avoid a bunch of the pid issues...

I just tried the VS 2013 update 2 "Child Process Debugging Power Tool" at http://blogs.msdn.com/b/visualstudioalm/archive/2014/11/24/introducing-the-child-process-debugging-power-tool.aspx -- which should do exactly what we want. It didn't work. We should be launching using CreateProcess(), so I don't know why it wouldn't be working.

Here's the alternate approach, with "-waitfordebugger" and attaching by pid. This works, but you have to do the same manual attach on startup step, click No, etc. At that point, it's not clear what using vsjitdebugger.exe gets you -- just a -waitfordebugger option would be enough, and then you can manually attach using VS. We need to figure out a way to forcibly, no-questions-asked, debug a given process using a given VS instance.

-waitfordebugger via an env var and no vsjitdebugger.exe goop, combined with a variation of the Chromium "attach to all chromium processes in a given path" script found here: https://code.google.com/p/chromium/wiki/WindowsVisualStudioMacros#Automatically_grab_chromium_child_processes could work well. You'd just keep hitting the "attach to gecko processes" button until you got all of them. If you didn't care about debugging on startup, you wouldn't even need -waitfordebugger, just the attach button.