How to debug startup exceptions with service hosted in IIS? - c#

I have my service running in IIS. I have a non fatal exception occurring and being logged on startup.
How do I attach Visual Studio to IIS so that it also debugs the startup?
I know I can attached visual studio to the w3wp.exe to debug while its running.

Add the following to your application's start up code:
System.Diagnostics.Debugger.Break();
When this line is hit, you will be prompted to attach a debugger to the process. See Debugger.Break for more details.

If you want to live debug you must have the Remote Debugging tools installed on the web server. Make sure to use the correct version for the version of Visual Studio you are running.
Compile your project in debug mode, make sure "Emit debug information" is checked in the Advanced Precompile Settings.
Deploy your project to the server. It is critical that the code in visual studio matches exactly what you deployed. Do not try to debug against even minor differences in code (web.config setting differences are ok).
Run the remote debugging tools on the server with an administrator account. You should see it say "... Waiting for new connections".
In visual studio, use Attach to Process from the Debug menu to attach to the w3wp process on the server. Make sure the Qualifier is the server name:port number that the remote tools is listening on.
In some cases, you may need to click the "Select..." button in the Attach to Process window and select only "Managed (v4.5, v4.0)" code types instead of letting it automatically determine code type. If your break points never get hit because no symbols were loaded, this could be why.
Tip: assign a specific app pool to your IIS application so it is easier to identify in the Attach to Process window. You may have a bunch of w3wp.exe processes and you may not know which one you want to attach to.
As an alternative to live debugging, you could run an intellitrace on the server, bring the trace file back into visual studio and step through the code like it is a recorded session. This is a whole other set of instructions involving powershell. I prefer live debugging if it is an option.
UPDATE:
To step into Application_Start(), recycle the App Pool and then attach Visual Studio before any requests come in to be sure you are debugging when you (or anyone) makes the first request.

You can also use below code snippet. It is equally handy -
System.Diagnostics.Debugger.Launch();
Wheneever you place it in code, it launches Visual Studio's JIT debugger at that very spot as shown below. As already suggested in the accepted answer you can place this code in application's start-up code at the very first line:
You can then choose and attach to any new or already running instance of Visual Studio across all versions installed on your machine. Hope this helps someone!

Related

Debugging a process that runs as Local System (Windows Service) in Visual Studio

We have a Windows Service that runs as Local System. Luckily, I can run it as a normal console application. The application won't execute if we start it as a Current User because it tries to access some certificates that are installed as Local System. So, in order to debug the process, I had to start Visual Studio as Local System with the following command -
psexec.exe -i -s <Visual Studio Path>
And I was able to attach to the process without any issues. But the problem happens when I try to debug it. Once, it hits a breakpoint, I get the Edit and Continue popup with the below message -
Edits were made which cannot be compiled. Execution cannot continue until the compile errors are fixed. Refer to the Error List Window for further details.
But no edits were made to the code, and I didn't find any errors in the Error List Window.
Some Stack Overflow posts suggested disabling the Edit and Continue option in the Visual Studio settings. That seems to be a good workaround, but I would like to know if there are some other good solution to fix this.
Thanks in advance :)

vshost.exe not terminating properly in Visual Studio 2015

I am in charge of testing VS 2015 and how it works with our current applications for my employer. We currently use VS 2013 for everything we have, so I know there are no issues there. The problem I am having is that it appears the vshost.exe isn't terminating correctly or something. I have not narrowed down the exact issue but so far that is what I believe.
Here is how I get my error:
Run my app in debug
Open a few windows
Hit the "Stop Debug" button (the little red square)
Clean Solution
Rebuild Solution
After my rebuild I get the following errors in the EXE:
Error Could not copy "obj\Debug\APP.exe" to "..\..\bin\APP.exe". Exceeded retry count of 10. Failed.
Error Unable to copy file "obj\Debug\APP.exe" to "..\..\bin\CRM.exe". The process cannot access the file '..\..\bin\APP.exe' because it is being used by another process.
If I open the Task Manager and manually end the vshost.exe process I can successfully rebuild again, no issues. If I take the same steps, however, I am no longer able to build.
I tested these steps in 2013 and did not have an issue.
Also note that disabling the "Enable the Visual Studio hosting process" does alleviate the issue, however I do not want to disable this option.
Has anyone else had this issue? I know we are still early in release. Any suggestions/solutions to try? Is it possible there is something wrong in our code (which I highly doubt since I would then get the error in 2013, most likely).
Thanks for any help I receive!
EDIT: This is a WPF application written in .Net 4.0 using C#. Also, I have verified that the issue also occurs if I exit the application normally (IE I open a window then close it with the shutdown mode on LastWindowClosed)
SECOND EDIT: This is a new issue that presented itself in Visual Studio 2015 with the addition of the new live diagnostic tools.
I have found that if I have the "Enable Diagnostic Tools while debugging" option enabled in the debug settings I get this error. If I disable this option, the error goes away. I am not sure if this is a bug in Visual Studio but I would assume so, unless I need to do something else to shut them down properly. If anyone has comments or concerns, feel free to leave a note.
Probably late for the original question (and I see that he had a workaround), but as per MSDN, VSHOST.exe is only an enabler for improving Debug performance or facilitates scenarios such as partial trust debugging. If you do not need that support or can bear the cost of starting a process and attaching the debugger on each debug session, go ahead and disable the hosting process from project designer -> Debug -> Clear the box "Enable Visual Studio hosting process"

How to edit C# code in Visual Studio while running, NOT with edit and continue

I'm working on a project in C# where the code relies on polling a web server for a report, this can take anywhere from minutes to an hour to generate and respond. I'd like to be able to run my project and see how it responds, but also continue working on other parts of the code. I don't want to do Edit&Continue, because that will pause or modify what I'm running.
I've tried running it in Release mode so I'm not debugging, but Visual Studio still complains that I cannot edit code while debugging. Any advice? Is this possible?
Thank you in advance for any help or information.
When you F5 a project, whether it's Debug or Release, Visual Studio will attach to the process, locking the file. Try running without attaching (Ctrl+F5).
A rebuild will try to overwrite your executable, which probably can't be done because it's locked while running, even without the debugger attached. This way you can't compile or debug your newer version while the older one is running.
Deploy the executable somewhere else, run it, attach to it using another instance of Visual Studio and continue editing in your first instance.
Run with Ctrl-F5 rather than F5 (or the Run button). This is "Start Without Debugging," also available from the Debug menu.

VS Debug DLL invoked from system service

I am developing a DLL (in Visual C# Express) with some plugin logic for an application.
Is there any way to debug this DLL, once it get's used by the application? The application is running as a service on Windows, and it's a COTS application, meaning that it's not a C# project I can start debugging from.
I am aware that there are limitations regarding debugging in Visual C# Express. Is this task possible in Visual Studio Pro?
What I want to acheive is to be able to step through the logic, set break points to see what happends when the call comes. Any clues?
I am not sure about VS Express but, normally,
Open Visual Studio
Open your Solution (Windows Service Project)
Debug -> Attach To Process
Select your Service from Available Process List
You may use breakpoints and other stuff.
Hope it helps.
While I'm not entirely sure how this works with services specifically, you can set an arbitrary debug target.
In the debug panel (in project properties), you can set any executable or other command as the debug target. The process spawned by this command will have the debugger attached, regardless of whether where the executable came from. There are no requirements that the target be a C# project, or any Visual Studio project. This should be available in both Express and Pro. It's possible to attach to a later process (if you have a launcher), but that's probably beyond your current scope.
You then set breakpoints in your code as usual, and when the code is hit (regardless of whether your code calls it or the host executable), the breakpoint will be triggered. Depending on how much information you have about the host, you may be able to effectively debug it as well; even if you have no information, you'll be able to step through the assembly.
The only requirement here is that the target load and run your code. Depending on the context (plugin to a program, injected dependency, whatnot) this is of varying difficulty. The technique is used in a number of places, particularly plugin systems where you may not be able to debug the actual host, but still want to do so with your plugin.
Another, slightly uglier variation, is to force the host to break and self-identify. This is only useful for debugging, as it's very disruptive. The typical method is to show a message box (modal) with the process ID. The process will then be suspended until the message is dismissed, and a debugger can be attached. This becomes more difficult with services, although there are still ways to publish your information in a blocking fashion.
You could use the System.Diagnostics.Debugger.Break() method.

Debug Class library

I have a c# class library that I am calling from Classic ASP.
Is it possible to debug this using visual studio? Break points in the class don't work, which isn't surprising.
I am running this on iis7 in the browser, rather than through Visual Studio 2010 because of the fact that I'm using a classic ASP page. Do I need to get this running in Visual Studio in order for this to work?
I also tried to use Response.writes, but they result in:
The name 'Response' does not exist in the current context
You need to attach the debugger to the process (either IIS or another debugger that you are using to debug your classic ASP application) that is loading the assembly.
Under VS2010 go to Tools -> Attach to Process (probably the same under 2008 as well).
try to add in the code of the lib: System.Diagnostics.Debugger.Break(); where you want to break. Also ensure the lib is compiled and deployed with the pdb symbols. When the code will reach the instruction, IIS will throw an exception. The system will ask you to attach a debugger, and you're on the way.
I actually wrote an article regarding this:
http://www.jameswiseman.com/blog/tag/visual-studio-2010/
From the article:
Open Visual Studio 2010
This is easy enough if you have it installed. Might be a bit tricky if you don’t ;-)
Open your website in Visual Studio
Again, easy enough.
Fire up your web site.
I.e. open your browser and navigate to the website.
In Visual Studio, click ‘Debug’ Menu -> ‘Attach to process’
You may need to tick the box labelled ‘Show processes from all users’
‘Inetinfo.exe‘ if application protection is low or ”dllhost.exe‘ if application protection is higher. You may get an ‘Attach Security Warning’ popup. If so, continue On. It’s a bit scary at first, but if it’s your own app on your own PC, then you’ll be ok.
If you’re worried about this, follow the advice on MSDN.
Add a breakpoint to your code, and navigate to a location where you will hit it.
Troubleshooting - Registering pdm.dll
This worked on the first occasion that I tried it. Subsequent attempts were not so successful, and I found a few things that I had to do.
When trying to attach to ‘Script Code’ I got the following warning in the IDE.
Warning: Cannot debug script code. The
correct version of pdm.dll is not
registered. Repair your Visual Studio
2010 installation, or run
‘regsvr32.exe
“%CommonProgramFiles%\Microsoft
Shared\VS7Debug\pdm.dll”‘.
Just follow these instructions.
Troubleshooting - Restart IIS
This also helped on one occasion. Can’t really say why.
You will make your life much easier all round if you wrap you .net classes in a web service then call the web service from the classic asp pages.
For debugging, attach the debugger to the process as described in other answers.
For tracing, I find very handy the combination between System.Diagnostics.Trace.Writeline() in the class library and an OutputDebugString listener like DebugView.

Categories

Resources