CODEWITHSUNDEEP
c#asp.netdebuggingiismanaged
user2184057
user2184057

Reputation: 964

Cannot debug ASP.NET Application on Localhost anymore

I've got stumped by problem during development of my ASP.NET application. I cannot debug it any more after attaching debugger to a process. Recently I was changing some windows features and checking IIS settings but as far as I remember I was able to debug my app till today.

Ok so what's going on.

I attached debugger and nothing happens no symbols are getting loaded (I am absolutely sure that Build -> Configuration and stuff looks correct in terms of debug etd). That symbols are getting generated and that app is working on dlls which I compile the only problem is that no matter what I do - symbols are not getting loaded.

I've got 2 traces which could lead me to the cause 1st:

The first one is strange application type when attempting to attach a debugger using visual studio. Normally all other apps are using Managed (v4.0......),x64 (I am right now talking about Window with all process running on computer Debug -> Attach -> type column)

but this app for some reason is using Script, Managed (v4.0......),x64

The other one is that when I've debugger attached to the application and open Debug -> Windows -> Modules the only one that is listed is:

**Script Code (Microsoft Active Server Pages)   Script Code (Microsoft Active Server Pages) N/A N/A Symbols loaded. Script Code (Microsoft Active Server Pages) 1               [29896] w3wp.exe**

Which kinda looks like some precompilled stuff. (I do not recall enabling any kind of recompilation).

I've tried recreating app on IIS along with switch app pool yet it's still the same. What's even more after checking diff of web config I don't see any kind of change which could lead to such behavior.

I was working with this application for like 8 months and never had a problem like this.

Thanks in advance for your tips.

Kind Regards.

EDIT:

Images

Modules

Processes

Upvotes: 1

Views: 495

Answers (1)

dlkmp
dlkmp

Reputation: 135

I've had the exact same issue and could solve it by moving the site to a different application pool. The target application pool already had an application assigned which I could debug (showed up as Managed (v4.0......),x64 in process selector) and once I moved the problematic site over, I could also debug that site.

I didn't figure out what exactly causes the behavior in the first application pool but maybe this helps someone to quickly solve this problem until someone comes up with a better analysis.

Upvotes: 1

Related Questions