I recently came across an issue I didn't realized before. The thing is that for instance: I want to delete an user and if a stop the debugging before the execution reaches that "delete" method, instead of stopping and NOT delete the user, it does delete user anyways.
Any bug related? What should I do?
Thanks in advance!
See https://msdn.microsoft.com/en-us/library/406kfbs1(v=vs.100).aspx:
"Stop Debugging terminates the process you are debugging if the program was launched from Visual Studio. If you attached to the process, instead of launching it from Visual Studio, the process continues running. If you want to terminate attached processes, you can terminate a single process from the Processes window or terminate all attached process with the Terminate All command."
Related
I am debugging an ASP page with visual studio 2013.
So, i set a breakpoint, the breakpoint gets hit, and the execution gets on hold.
Now, i just want to abort the current request stop executing the code for the current request (which is on hold as it had hit the breakpoint), without having to stop debugging and run again the project.
This seems too simple, yet i haven't figured out how to do it.
Let me explicity state that clicking "restart" is not what i need, as "restart" is just a shortcut to stop project and run again.
Based on our conversation in the comments, I am placing this as an answer.
What you are asking for is not part of the visual studio debugging process. unless you manually return from the request after the break point the process is going to continue running. When debugging you are just an observer of the process. Either the code kills the process via exception or returns from execution, or you kill the process externally.
It does not looks like what you are asking for is possible, and that is by design.
I'm debugging some of my code on Visual Studio. This code belongs to a custom Session Provider that I created, and I'm debugging it on my web application launch. It starts initializing my provider, and on that function I have a breakpoint that is being hit successfully the first time. However, that same breakpoint is being hit again, but it has a small blue icon and if you hover over, this message is displayed:
The process or thread has changed since last step
On my research I've found several kinds of answers, from people saying that the breakpoint is hitting a different assembly to some others saying that the breakpoint has been hit from a different thread.
Does anybody know what does this really mean?
When you have multiple threads running the same piece of code and you have a breakpoint there, Visual Studio will stop the execution every time any of those threads hit the breakpoint.
This will happen for every thread, in an unpredictable order.
When you are debugging step by step on your code, another thread can execute the code that you were debugging and hit the breakpoint. Visual Studio will let you know about this by putting that blue circle with the exclamation mark on the next statement arrow.
See more here: Debug Multithreaded Applications in Visual Studio
This icon simply means the breakpoint was hit on a different thread than the last thread you were on. It doesn't affect the program behavior at all.
I am running/debugging an asp.net mvc3 application from within Visual Studio 2010.
Anything static in nature is not called when I re-run the app from within Visual Studio.
(or even something simple like Application_Start())
Each time I want to run the webapp 'properly' I need to kill WebDev.WebServer40.EXE in the task manager before anything static is called again.
q1) Is this normal, and if Yes, why?
q2) If no, then I would expect the ASP.NET Development Server to be restarted each time I restart a debugging session. How can I turn this on?
UPDATE:
Recompiling sometimes causes Application_Start to be called, not always.
I've resorted to calling a batch file in the prebuild, eg
kill_WebServer40.bat
which contains
taskkill /F /IM WebDev.WebServer40.EXE
exit 0
If you embed those two commands directly into the pre-build textarea your compilation will fail if the WebServer isnt running already. This linked helped fix that.
Surprised this wasn't discussed more/previously - when developing an app, as if you have any static data/caches and you want to run the application 'clean' you would run into this issue.
Yes it's normal. It will restart if you touch the web.config or recompile. The development server continues to run the application in the background after you stop debugging.
You can stop the development server in the task tray by right clicking on the icon and choosing stop.
There isn't a way to force a application restart every time you hit debug. This would only be needed for the edge case where you are debugging application start up. Just hit rebuild before debugging and it will have the desired affect.
I am trying to debug some code in my ASP.NET web app.
I set a breakpoint in one of the page events of the page's codebehind, and this once came up with a special icon in place of the red breakpoint saying symbols have not been loaded and the breakpoint will not be hit.
This error has not repeated itself but why can't I hit the breakpoint?
Also, when I press stop, I get a popup in VS stating:
Stop Debugging In Progres...
Debugging is being stopped but is not yet complete. You can force debugging to stop completely, but any processes attached may terminate.
This window will automatically close when debugging has completely stopped.
Completely stop
I also don't get the website appear in my browser either when starting to debug. :(
To make things worse, I have a line of code like this in my page's codebehind:
RssFeedSites = opml.Parse(filestream);
I am putting the problematic breakpoint on this line. But I have a programatic breakpoint in the Parse() method of opml, but this does not get hit, either.
Thanks
Could you check if the dll is perhaps in the GAC? If it is it is probably an older version and the GAC has priority over local dll's. So if the dll is in the GAC visual studio is using that (older) version instead of the newly built one.
the debugging host could not find the correct pdb's to match your executable or the debugging host is failing.
Check your build, are your PDB's all up to date and in the correct directory to be found ?
Check the debugging host process if its having problem. If your using visual studio hosting process, then has the vshost.exe process somehow terminated prematurely ? If your remote debugging, check the remote debugger. Check your web server as well. If the debugging host process fails to respond, visual studio will be stuck when trying to debug.
I don't recall the specific reason for the message when I have seen it, but I always ignore it, because the symbols get loaded when the page is executed and it always hits the breakpoint assuming it's in the process flow of the page.
If you can't hit ANY debug points and you are running from local IIS, you will need to attach to the working process(w3wp.exe). Tools->Attach to Process.
Looking at what's running and nothing jumps out.
Thanks!
It should be w3wp.exe
EDIT: In line with Darren's comment, you should also check the "Show processes from all users" in Task Manager if that is where you are looking for the process.
Just to add something here, process explorer comes in handy when trying to track down a process:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Beats task manager hands down and can be substituted.
make sure you have show all processes checked (in vs)
Furthermore if you need to look at the .NET/unmanaged stack just donwload Process Explorer and look at your w3wp.exe processes to examine memory and other stats without having to do a remote/local debugging (just look at the .NET Tab on the properties of the process). It will show all the .NET performance counters for that particular process.
Awesome tool!
Using TaskManager should show you the process W3WP.exe is the IIS worker process, if you have multiple instances adding the Column "Command Line" will show you which Application Pool is being hosted on each of them in the -ap switch.
Also, in the IIS Manager UI there is a "Worker Processes" feature that if you double click that you will see the list of processes, Memory and CPU they are consuming, and double clicking the instance will show you the list of executing requests on it, really useful when trying to figure out a "misbehaving" request.