30

I got a break point on the first line of Application_Start(), but Visual Studio wont break on it.

Visual Studio have attached itself to the IIS working process:

Auto-attach to process '[2092] w3wp.exe' on machine 'SRD00510' succeeded.

My breakpoint in the home controller do work.

update

I've tried:

  • iisreset
  • restarted visual studio
  • Rebooted.
  • Tried to reinstall aspnet (aspnet_regiis -i)
jgauffin
  • 99,844
  • 45
  • 235
  • 372
  • Try rightclick on proj. debug > step into new instance. This way you can see whats happening from the start.. – jrb Sep 10 '12 at 14:27

9 Answers9

60

Reading your question, I assume you are using IIS for debugging, not Visual Studio Development Server.

In this case, debugging application start is tricky, because it is only called once when the application pool is started or recycled. When Visual Studio attaches to the process, Application_Start has already been running.

The trick is to make the application pool recycle without killing the process you are attached to.

Do the following:

  1. In Visual Studio (must be run as Administrator) set your breakpoint in global.asax.cs and start debugging as usual (F5). The page opens in your web browser, but the breakpoint isn't hit.
  2. Now the trick: With a text editor, open web.config from where it is served by IIS, change it (e.g. enter a blank line somewhere) and save it. In contrast to recycling the application pool in IIS, this lets the application pool recycle (and thus running through Application_Start in global.asax.cs the next time the web site is called) without killing the process you are attached to.
  3. In your web browser, reload the page. The breakpoint should be hit now!

That works for me (IIS 7.5, VS2015).

Jochen
  • 862
  • 8
  • 4
  • 1
    This still works with a minor modification between step 2 and 3. Changing the web.config forces you to stop debugging, but you can reattach to the process and continue as you stated. – Danation Feb 19 '16 at 19:41
  • @Danation: You're right. You shouldn't use the Visual Studio instance you're currently debugging with. The main point is that you edit web.config on the place on disk from where it is served by IIS. That may be a different location than the one where your Visual Studio project resides. Look into IIS where the site's root directory is located on disk. Changed my answer accordingly. – Jochen Aug 10 '17 at 16:57
14

Place this line in your Application_Start().

Debugger.Break();

This will present you with a dialog which will allow you to select a debugger. You might need to restart the application pool.

Razor
  • 17,271
  • 25
  • 91
  • 138
  • 1
    That gives me a new instance of visual studio. – jgauffin May 30 '12 at 13:31
  • Usually, you get a "chooser" form to select a new VS or currently running VS. You don't see that? – spender May 30 '12 at 13:38
  • Yes, but I can only select a new visual studio instance. – jgauffin May 30 '12 at 13:43
  • In some instances it will list the currently running Visual Studio instance and let you select that, other times you'll need to start up new instance. Either way, you can debug using this method. – Razor Jun 01 '12 at 12:22
  • If you want to use the instance of Visual Studio that you already have open, don't use "Start Debugging" in that instance. Instead, use a browser to invoke your app. Then, you should be able to use the existing instance. – Holistic Developer Jan 14 '14 at 17:13
6

Application_Start() only runs once, when the application starts. A few things that restart the application are:

  • web.config changes
  • recycling the worker process - you can do this in IIS Manager or by running iisreset at the command line.
jrummell
  • 42,637
  • 17
  • 112
  • 171
  • I've killed the w3wp with task manager and tried to change web.config. – jgauffin May 30 '12 at 13:16
  • That's strange ... if you're already attached, changing the web.config should do it. Are you certain the code at the break point is being executed? Can you move it to the start of `Application_Start()`? – jrummell May 30 '12 at 13:52
2

My solution is to switch to using the 'Visual Studio Development Server' to deal with the application class (Global.asax) issues. When done I switch back to IIS.

David Perlman
  • 1,460
  • 1
  • 12
  • 32
0

I assume you're loading the application by clicking the "debug" button in Visual Studio? That's what I'm doing (in VS 2012) and seeing similar problems. Pressing that button the first time starts the application and correctly hits the breakpoint. But it seems like after I stop debugging the application itself keeps going. So, future attempts to debug just attach to the existing process.
There's a "restart" button next to the "stop debugging" button, so I'd assume clicking that at least would change things. The debugging app does not show up in IIS manager, so I can't stop it there. Likewise, iisreset doesn't catch it either.

Only thing I've figured out so far is to change a line of code, thereby forcing visual studio to trigger a build and then it kills the existing proc and starts over. Kind of annoying if I just want to step through there multiple times.

I don't consider this a suitable "answer", but it might be a helpful workaround for you until somebody does come in with a real answer.

Mike Ruhlin
  • 3,546
  • 2
  • 21
  • 31
0

I've got around this problem before by doing this:

  1. Run a clean on my solution (Right click the solution node and click clean)
  2. Close solution
  3. File -> Exit on visual studio
  4. If you have multiple instances of visual studio running then exit out of all instances. Ensure "devenv.exe" is not listed in the processes in task manager
  5. Delete the user options file (.suo), usually in the same directory as your solution (.sln) file
  6. Recycle IIS worker process or if using the development server, kill that process

Now open your solution and give it a shot. (keep your fingers crossed :))

Sudhanshu Mishra
  • 6,523
  • 2
  • 59
  • 76
0

Whenever you run an application for the first time, or say start an application, there is an ASP.Net Development Server - Port [port number] that starts,

Application_Start() runs once in the course of an application.

If you want the break point to be reached , you have to stop the ASP.Net Development Server Port and run your application again.

Ravi Sankar Rao
  • 1,050
  • 11
  • 26
0

if [2092] w3wp.exe is a service that you made, try this : stop service -> rebuild service project -> start rebuilt service -> try to debug

WholeLifeLearner
  • 455
  • 4
  • 19
0

If using IISEXPRESS is not an option, as @David Perlman mentions, I would go for a Logger. Log4Net or NLog are both good. It's good to have a logger in the longrun, for instance in production environments.

namespace DataService
{
    using NLog;
    public class Global : System.Web.HttpApplication
    {
        private Logger log; 
        protected void Application_Start(object sender, EventArgs e)
        {
            LogManager.LoadConfiguration("nlog.config");
            log = LogManager.GetCurrentClassLogger(); 
            log.Error($"Read this line in the log specified in nlog.config");
        }
Tomas Hesse
  • 385
  • 3
  • 10