Is it possible to debug Global.asax?

A simple way to break in Application_Start() is to use the System.Diagnostics.Debugger class. You can force the application to break by inserting System.Diagnostics.Debugger.Break() where you would like the debugger to break.

void Application_Start(object sender, EventArgs e) 
{
     System.Diagnostics.Debugger.Break();

     // ...
}

Application_Start() is invoked once per AppDomain. If you're not hitting your breakpoint, it means the AppDomain was already created, so do the following:

• In your quick-launch bar, there is an icon for the VS web server (its the one which says "Local Host Some Port"). Right click and choose "Stop" or "Close". This should kill the AppDomain.
  • If you're using IIS, you need to restart your site manually.
  • Alternatively, modifying the web config or Global.asax file is usually enough to restart the AppDomain.
• Restart your debugging, you should hit your breakpoints now.

Check that your web application is in debug mode (<compilation debug="true"> in web.config).

If you're using developer's IIS started by VS, just restart it or rebuild application.

If you're on normal IIS you have two options:

1. For web-site is configured to work with development folder (where you VS web project is deployed) you just have to restart application pool set for that web-site and start debugging before first request reaches server (you can always restart app pool during debug).
2. For web-site that works on another folder or even on remote server you have to attach to the process. To do this you need remote debugger installed on remote machine or your own (depends on web-server location) and use Debug - Attach to process menu, enter computer name and then select a process to debug. It is usually a w3wp.exe working in managed mode type.

Yes, it is normal.

Application_Start() is processed by IIS.

But all other methods, for example Session_Start, and all others, except Application_Start() can be debugged normally.

Maybe you should try:

• stopping development server in taskbar
• switching the configuration from release to debug

Another alternative to the accepted System.Diagnostics.Debugger.Break(); would be

void Application_Start(object sender, EventArgs e) 
{
   System.Diagnostics.Debugger.Launch();
   //...
}

which shouldn't break the code and should start the debugger even if the service were started with different rights.

For me, my debug breakpoint already executed in IIS by the time the debugger is attached. So the solution was to alter global.asax with a little space and save the file. After refresh, my breakpoint is now hit.

Solution here: https://wakeupandcode.com/hitting-breakpoints-in-global-asax/