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.
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.
Basically, I'm trying to carry out a number of tasks while a Visual Studio instance is running.
I have not been able to find anything yet in the Visual Studio SDK reference which is analogous to a background thread or IsRunning or anything like that. All I can do so far is respond to very specific events such as the view changing or the cursor being moved.
I don't even understand what event fires when the Visual Studio instance finishes loading.
Surely there must be something pretty big that I'm missing here? What manages the lifecycle of a Visual Studio instance?
So nothing prevents you from launching a background thread and doing work there. All sorts of components do that all the time. There are some ways you can register your package to load in various scenarios, and from there you could always launch a thread.
Be careful of course with any of these -- if everybody did "I'll run a background thread once VS loads", your CPU cores would be very, very busy! There's an older concept in VS called the "idle loop" where some code can be registered to run whenever the UI thread doesn't have a message to pump, and the internal joke is that the idle loop is never idle.
It stops responding after a few seconds of being idle. I have to restart it every time this happens.
I have tried putting startMode="AlwaysRunning" into my applicationHost config, but nothing changed.
The output of the console is just a bunch of
The thread X has exited with code 0 (0x0).
I don't think this is related to idleTimeOut either, because the website completely stops responding; it just hangs.
applicationHost if anyone is interested (too large to post here):
http://pastebin.com/quVMXPHP
Let me know if you need further information.
Are you sure it's from being idle? By default, every time you stop debugging, IIS Express unloads the website, and quits entirely if there's no other websites running. You can disable this by unchecking Enable Edit and Continue in the project properties under the "Web" tab.
If it happens more randomly, then IIS Express may actually be crashing. Check in the notification area of the taskbar for IIS Express, make sure it's there, and (by right-clicking) ensure your web project is still loaded (in the list). If it's actually crashing, you most likely have a memory leak, infinite loop, or something similar going on somewhere in your application that's overloading the process. There's no much we can do to help you with that, without being able to examine your entire codebase. You'll just have to trace and profile until you find it.
On my work computer, debugging in Visual Studio 2008 (SP1) seems to work somewhat different from what I'm used to. I have two problems that might or might not be related.
First problem:
When I'm running a web application in debug mode, and an unhandled exception occurs, I get a Yellow Screen of Death immediately. Normally my code just breaks at the line throwing the exception, allowing me to inspect the state of the program.
For some reason, the only way I can do that on my work PC is to set a breakpoint on the line that threw the exception, and repeat what I did. It's been annoying me for a couple of days now, but I have no idea what could cause this. Any ideas?
Second problem
The WCF webservices used in the site I'm debugging behave a little odd when it comes to debugging as well. Most of the time, setting a breakpoint in the service won't have any effect when it executes that code. At first, I figured I had to attach to the wcfhost process, but that isn't it. When I put a breakpoint on the line where it calls the service, and use F11 to step into the method call, I do end up in the service's code and I can debug all I want.
Why would stepping into work, while breakpoints get ignored? Is there a way to change this behavior?
For the 1st problem:
In Visual Studio go to Debug/Exceptions
You should see three columns in the list: "Name" (type of exceptions), "Thrown", "User-handled"
In the "User-handled" column you have to activate the checkbox for "Common Language Runtime Exceptions".
Note, if you shouldn't see the "User-handled" column, go to Tools/Options, then click on "Debugging" in the tree and on the list activate "Enable Just My Code (Managed only)". Then the column "User-handled" should be visible in the other dialog and you can activate the according checkbox.
For the 2nd problem:
It seems to me as if I have experienced a similar problem. I guess you have to set the breakpoint there, because the WCF service runs on a separate "webserver" (your local VS webserver). Therefore it isn't like a normal method call within your same application and therefore you have to set the breakpoint on the WCF method that gets called. I always did it this way and it worked perfectly for me.
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.