I like to stop the execution of a debug thread that I run in IntelliJ Ultimate 2019.3.
I can stop the entire JVM process, but that will require to restart the web application that takes a lot of time to spin up.
I found this request for such a feature (back from 2015), but I see no new way to do it.
Following y.bedrov comment, the solution was indeed to get to the "Throw Exception" wizard and then to enter there
new RuntimeException("error")
Related
I need to debug a dll that's getting loaded on a specific application pool process. I'm using WinDbg, and so far I have successfully found the correct w3wp.exe process. Problem is, the app pool recycles itself, sometimes before it reaches what I want to find (a very elusive second chance exception). Then, I need to start over.
How do I configure WinDbg to automatically attach to a w3wp.exe process that's connected to a specific app pool, every time it starts?
Another solution would be to get the crash dump - I tried using ADPlus.exe for this but it also needs to be started on a process and I didn't find a way to re-run it automatically on only the process I need AND every time it starts.
So to sum it up, I need a way to get a crash dump from a w3wp.exe process that's connected to a specific IIS App Pool when it crashes on a second chance exception, while the process gets restarted once in a while (not enough time for me to run the debug tools manually each time).
Eventually, I discovered this awesome tool called DebugDiag, which is an official Microsoft tool. It has a nice interface that allows collecting dumps on certain events, such as exceptions, and creates very useful logs.
On top of that - it has a special section specifically for IIS debugging, which allowed me to select the app pool I was interested in.
Download available here.
I've recently picked back up a year old MVC5/WebAPI2 (and SignalR) application which ran just fine under VS2013.
In VS2015 I however keep struggling with what appears to be hanging debug sessions: When starting a debug session VS2015 hangs on "Build succeeded" with no output in the console. The solution is to terminate the IIS Worker Process (which appear locked at 20-30% CPU Usage) via the Task Manager. Upon doing that VS throws a general error message and stops. When retrying once again it works normally until next stop-then-start.
It makes no difference if I stop (Shift+F5) the debug session or restart (Ctrl+Shift+F5) it, either appears to lock up the IIS process. What however does work is going to Debug -> Terminate All, then the debug session starts without hick-up.
I have tried disabling pretty much all debug tools (including Edit-and-Contiune), but nothing has worked so far. I should also mention that running the application on IIS Express does not work at all: It hangs during startup no matter what.
Update: Attaching the error message that pops up if I let the debug startup process time out. I have of course tried all the suggested solutions which the "help" button takes me to.
Update II: It looks like the problem might be related to SignalR. I've been working without problem for the last hour or so, but now stepped into the part of the application which uses SignalR. After stopping and changing some code, the debug session would not start again.
Ensure that you turn on ‘Internet Information Services Hostable Web
Core’ along with all the other .NET / IIS feautes
Try to Change the IIS Settings Shown in this Article
I have the exact same problem, and the solution was to install signalR performance counters.
SignalR performance counters
Similar question with solution: SignalR makes IIS hang after rebuild
I'm trying to debug some web services. I have a number of integration tests setup. I want to attach the debugger to my web process and then execute one of my tests. The problem is Visual Studio doesn't seem to allow me to run a test while I'm already attached to a process. Is there any way around this? The only way I've been able to do it is set a breakpoint in the test prior to calling the webservice, debug the unit test, and then once it hits the breakpoint attach the debugger to my webservice process. That's too many steps.
No I don't believe you could. You can however start up a second instance of visual studio and attach it to your web process with the appropriate breakpoints.
I know this is late but it's still relevant, at least up to VS2019.
What I do to work around this is this:
Attach the debugger to my web service
Detach the debugger
Take note of the 'Reattach to process' shortcut. I think the default is Shift+Alt+P
Run the unit test
Immediately hit the reattach shortcut
Unless your test starts up exceptionally quickly, this method will reattach the debugger before the tests start running.
Allen's answer is better if your machine can handle 2 instances of VS.
I am new to programming.
I know only Start debug before. Maybe start debug suit for some small application develop better.
I found Visual studio IDE provide another method of attach to process for using.
When & Why must I use the attach debugging?
Such as multi-threading application debugging. Client/Service application debugging. etc. Thank you.
Sometimes you need to debug a process started by another program.
For example you need a reliable solution and in order to protect against access violations, memory leaks and other barely recoverable stuff, you have a master program and several worker programs. The master program starts the worker program and passes parameters to it. How do you debug a worker program which is not intended to be started by anything except the master program?
You use "attach to process for that".
Typically you do it this way: insert a statement that blocks the worker program for some time - for example, call Sleep() for 15 seconds. Then you kindly ask the master program to start the worker program. When the worker program is started it blocks and you now have 15 seconds to attach to it.
This way you can debug almost any issues - problems at early startup stages, wrong parameters, etc, which you wouldn't reliably reproduce with "run with debugging".
Attaching to a process is useful if you don't want to debug right from starting the process. For example, debugging usually slows down execution, so it can be quicker to start the app, get it to a state where a bug appears, and then attach a debugger.
It's also useful if you already have an external means of launching the process that you don't want or can't to import into the IDE.
Start debugging from VS launches an instance of the VS webserver and attaches the debugger to it.
Attach to process allows you to attach to any process and debug it, usually you'd do this to your instance of w3wp.exe running your code in IIS
Attach to process is mostly used when you can't run the application from Visual Studio.
For example, if it's a service or if it is a process that has run for a long time and now you want to start debugging it.
Sometimes you also want to debug a remote process, not on your machine - and you can do that using attach to process.
I have a main C++ app built in Visual Studio 2005, called A.exe. It spawns a child process, B.exe. I run process A in the debugger by hitting F5 -- the only way I know to hit breakpoints in process B is to wait for A to kick it off, then run Debug -> Attach to Process, and manually select B.exe. This doesn't work very well if I need to debug initialization code in process B -- I have to start putting in 10 second sleeps at the beginning.
Is there some trick in the vs2005 GUI that I'm missing?
I'm using native code, by the way.
Thanks,
Nathan
You can tell Windows to automatically attach the debugger when a certain process is started (by specifying the process name in a registry setting).
The details are here:
http://msdn.microsoft.com/en-us/library/a329t4ed(v=vs.100).aspx
You'd be hard pushed to make use of the debugbreak command in the child process as the debug process is not yet attached.
However, there is another that may be of use. Seeing as your creating the process, you'll have the handle to it. So give the DebugBreakProcess function a whirl.