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
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.
Related
I have a strange issue that occurs every day. I have recently been given a fellow developers laptop with Windows7 & IIS6 (they've left) and my previous laptop (WidnowsXP & IIS 5) has been recycled into the system, so I'm stuck with this one and didn't originally set up the system. Developing worked fine on my old computer, but on this one.
I am developing an ASP.NET website and after a while of editing, building, then going to localhost in IE, the page doesn't show. The process w3wp.exe isn't in my list of processes in the task manager. If I call iisreset.exe, this usually fixes it at first (i.e. going to localhost starts w3wp.exe and after a short while my page appears).
After a few runs of this, even this fix doesn't work, but I've found that if I close IE, then run iisreset.exe it fixes it.
Then after a few runs of this, I also have to close Visual Studio & IE, then iisreset.exe. Once I get to this stage, I can't make a single edit in visual studio without having to close it to run the web page. Note, I'm not running in debug mode. I've even tried editing in notepad++ for simple edits and I have to close that too before iisreset works!
Eventually I end up restarting my computer because these incantations stop working. I'm at the end of my tether. Does anyone know what could actually be wrong or where I should start looking for a real fix?
So I've been trying to figure out why the application pool keeps crashing every now and then, and I've pinpointed the page that is cau seems to be causing the issue.
When I open the site in the browser, and visit the Shipping cart page (after adding stuff to the cart), the entire browser becomes unresponsive, and I open Task Manager, and see that IE (browser) is using 99% CPU, so I right-click > Create DUMP > Try to read DUMP but WinDBG does not seem to like DMP files; won't read them.
So I move on, and try to figure it out without the dump files. I fire up Visual Studio, open the site in question, and then follow the same process (add stuff to cart, then visit cart page). And to my surprise, everything is OK.
Not sure what to do now. Any suggestions? How would you determine the cause of the hanging, when everything runs perfectly, locally - and when everything used to run perfectly online, but no longer runs fine online?
If the browser becomes unresponsive and eats 99% CPU, that's a client side problem; it most likely doesn't have anything to do with IIS or your server side code.
Could it be that you have some javascript in your page is buggy and goes into a busy loop? I think it's worth a shot to test this (use either IE's developer tools (F12), Visual Studio's javascript debugging functionality, or FireFox in combination with FireBug).
Edit
It strikes me as odd that your AppPool crashes, and in doing so, causes the web browser to turn non-responsive. With non-responsive, do you really mean that the browser itself stops working (i.e. navigating a page back or going to another url such as google.com is impossible?)
Anyway, if you think the problems occur on the server-side, you could try the following things (in order of increasing effort):
After an AppPool crash, check the windows event log (run 'eventvwr' from a command prompt) and see what information that gives you.
View the IIS log (you might have to turn it on first), see if it contains any weird request patterns, such as your page getting hammered)
Run your website from IIS, but attach a debugger from Visual Studio (under Tools, Attach to process - include only managed code) to the IIS worker process (usually w3wp.exe). If your page throws an exception, VS should be able to catch it.
Add more tracing to your page, the Global.asax's Application_Error seems like a particularly good candidate.
I have a Silverlight project that we use internally that I wrote - and since we've not had any need to work on it, it's been a while since I've opened the project. I opened it up this morning and everything is fine in terms of building, but whenever I try to debug I get the following error:
Unable to start program "http://mymachinename/mywebsite/index.aspx"
Of course, running it in Firefox works fine but no symbols are loaded. Running without debugging still throws the same error but IE loads up anyway...
Navigating to the website in IE works fine - SL app opens up, loads data etc etc, all looks good
I've Googled this all morning (usually quite good at finding info) and been through all the questions on SO and I can't figure out what's going on - there doesn't seem to be any messages in the event log, there are no messages in any VS output window, the w3wp just terminates immediately after starting (probably due to there being an error trying to open IE). I've tried reinstalling IE, cleaning/rebuilding, using local dev server, creating a new web project, turning on/off settings in IE9 etc etc
Nothing seems to make a difference - anyone got any experiences of this and has fixed it without doing one of the things I've already done? Any other suggestions?
Thanks in advance!
UPDATE
Just to be clear in case anyone asks - I get this problem when creating a new web project - i.e. everything I said I'd tried (above) didn't change the behaviour. It showed the same error no matter what I'd done so far (that includes a NON SL web project)
I've also tried attaching the debugger to w3wp that is running (the standard IIS process) and I can't seem to get it to debug (no symbols are loading), but that might be another issue altogether. I'm going to look at that next and maybe if I figure that out it might lead to fixing this issue
UPDATE 2
Debugging in Firefox works - I attached to w3wp with no success, then realising my stupidity (SL being a client side app!) I attached to the plugin-container.exe that FF runs its plugins in. This works. I can probably do the same for IE and just attach to IE, but why won't it start up from VS?! hair pull
UPDATE 3
Just in case anyone asks, the default browser is set to IE in VS. Also I've managed to debug by attaching to IE, it just won't start IE from within VS - annoying but I can live with it for now. If anyone does have a suggestion though, feel free...
For anyone's information in case they have this same problem, it ended up being that the port I was running my site on was also running a SharePoint site!
I created a new site on port 81 and used that for dev - not sure what setting on the other site caused the issue but it ended up working on port 81.
(xkcd)
I know that compiling nowadays is much faster than it was before. Yet, for me, it seems that compiling and especially running/debugging ASP.NET projects with the Visual Studio Web Development Server is incredibly slow.
Since the beginning of last summer, I've been working heavily on ASP.NET MVC projects. Of course, the best way to debug them is by using the web server that comes with Visual Studio. When doing that, I get horrendously slow loading times. Chrome dev tools typically report that loading one of my pages had a 3 minute wait time, followed by a short loading time.
I've seen these two questions, but they don't help. While I do most of my debugging work in Chrome, the same happens in IE.
Has anyone else had this problem before? If so, any tips?
Also, I doubt that the problem lies with the speed of my machine. This computer is really fast running Windows 7 and Visual Studio 2010, so I don't see why ASP.NET debugging should be so slow.
UPDATE: In his answer below, Jon Skeet suggested attempting to identify whether the problem is being caused by the environment or by the code itself. I created a brand new MVC project and ran it. The first test appeared to be much faster. However, after testing it a few more times, it's safe to say that the first test was an anomaly - usually, it takes as long as my big project (2 - 3 minutes). Thus, this is a problem with the environment. Thanks in advance for any help!
UPDATE #2: It's been a while since I updated this question. Here are some details I've gathered since my last update:
This delay is occuring on both of my development machines, both running Windows 7 and Visual Studio 2010
This delay is happening for all my MVC2 and MVC3 projects (but I haven't experimented with plain ASP.NET yet)
Plain/vanilla MVC projects experience the same delay as MVC projects with big codebases
Disabling IntelliTrace did not help
Disabling IPv6 did not help
I haven't found a solution for this problem, so I've been stuck with huge wait times. Does anyone know how to solve this?
There's no reason why it should take 3 minutes to start debugging something unless you've got something really strange going on.
I suggest you launch the debugger, try to navigate to a page and then just break into the debugger while it's loading. See where you're losing time. Maybe you're making some call on startup which is failing, but taking minutes to do so.
I've never experienced anything like what you're describing, which suggests it's either in your environment or in your code - and if it's a generally fast computer, that suggests it's somewhere in the code.
If you create a brand new MVC project and debug into that, does that take a long time?
You might also want to run Wireshark when you start debugging - see whether something in your app is trying to fetch a network resource of some description without you realising it.
This is due to the IPv6 DNS problem within Firefox and can be fixed by setting the network.dns.disableIPv6 setting to true within the about:config
Slow DNS response - Firefox on localhost and Visual Studio or Cassini
This is actually a known performance issue with MVC, caused by throwing a ton of exceptions internally on startup. If you have IntelliTrace turned on, this will wreck havoc with it. Try disabling IntelliTrace and see if that improves it at all.
Source: http://connect.microsoft.com/VisualStudio/feedback/details/535799/debugging-mvc-is-very-very-slow
Check out if this helps:
http://blogs.msdn.com/b/mahuja/archive/2008/07/08/resolving-very-slow-symbol-loading-with-vs-2008-during-debugging.aspx
I met the same problem these days, working under Win7, VS2010, and developing a Silverlight solution with 10+ projects. It takes about 3 minutes to launch IE, and waits 3 minutes to get back VS after closing IE. I overcame the problem by trying different ways. But the only valuable method:
Unload all projects not for debug
Start debug the solution (it works normal )
Reload other projects
VS works normal here. (VS works normal)
It seems the problem is just related with the VS environment on my side. It has nothing to do with ASP.NET Development Server or IIS.
I was having the same problem. It ended up being a problem with ColdFusion being installed on my local machine (as painful as it is for me to admit). ColdFusion puts Handler Mappings named AboMapperCustom-* that were causing the latency. I uninstalled ColdFusion because I no longer need it (thank God). Another solution could be to remove each AboMapperCustom entry through the web.config. Example:
<handlers>
<remove name="AboMapperCustom-15397" />
<remove name="AboMapperCustom-20358" />
<remove name="AboMapperCustom-47286" />
</handlers>
Make sure the 5-digits following AboMapperCustom- match those in your local IIS Handler Mappings.
HTH
On Visual Studio 2012 + Win10 x64, i've noticed that if you
go to the taskbar and find the asp.net dev server there,
right click it and do a "show details"
close the box (NOT 'stop', just close via 'x')
then the server loads almost instantly
I was wondering if there was a way to completely lock my code while debugging it within Visual Studio 2008. The code documents lock automatically when running as 64 bit applications, which I greatly prefer; however, I do most of my coding making add-ins for Excel, which is 32 bit. The result is that even though I target 'AnyCPU', the VS host knows that it is running within a 32 bit process and, therefore, the source code is not locked while the code is running hosted in Visual Studio.
I can turn off Edit and Continue by going to Tools > Options > Debugging > Edit and Continue, and then unchecking the 'Enabled Edit and Continue' check box. This does not completely lock the code, however. This does prevent any edits in the code from being executed in the current run, but it does not prevent mouse clicks or keystrokes from actually changing the code.
Again, when working with 64 bit applications this does not occur -- the code is completely locked. I greatly prefer the code to be completely locked for at least a couple of reasons:
I can accidentally hit a key or the like while debugging, which I definitely do not want to do. It's rare, but it is an issue.
Many of my automated tests drive the user interface via SendKeys. When stepping through such a test using the debugger, however, I can sometimes forget that some of the aspects involve SendKeys, which means that keystrokes wind up getting sent to the Visual Studio IDE instead of Excel.
In issue #2, above, the unit test fails, which is fine -- my bad -- but having all the keystrokes sent to the code module and destroying my code is completely unacceptable.
Does anyone have any ideas here? Can one completely lock the code when running hosted in Visual Studio while compiled against a 32 bit CPU?
Some related posts on this issue, but none of which directly address this:
How to: Enable and Disable Edit and Continue
“Changes to 64-bit applications are not allowed” when debugging in Visual Studio 2008
How do I enable file editing in Visual Studio’s debug mode?
How does “Edit and continue” work in Visual Studio?
Can we edit our code while running the application
Editing C# while debugging
Thanks in advance for any help or ideas...
Mike
Here is a trick I use under Visual Studio 2005 (don't have a chance to test under Visual Studio 2008, but it should work):
Open the executable assembly's properties
Go to the Debug tab
Check the Enable unmanaged code debugging checkbox
The code documents should stay locked, even when a breakpoint is hit, and any attempt to change it should trigger a popup saying "Changes are not allowed when unmanaged debugging is enabled".
Hey there - sorry I can't help you with completely locking your code - I have the opposite desire: to completely UNLOCK it during debug, but I can help you with your second issue.
I suggest that you consider checking the active window before sending any keys and if the active window is other than your target site, pause the execution of your test until focus is returned that that window.
I know it's not the solution you want, but it probably wouldn't hurt to prevent other similar issues.
Best of luck!
Adam
Here is the best I could come up with. It works, but there are some steps you may not want to take.
Essentially, the technique is to set the files of your project to Read-Only when you run the application, and then set them back to writable once your application ends.
However, in VS2k8, by default, setting a file to Read-Only still allows you to edit the file. You need to first turn off the setting "Allow editing of read-only files..." in Tools > Options > Environment > Documents.
Second, you need to add the following key to the registry as a DWORD and set its value to 1:
HKCU\Sofware\Microsoft\Visual Studio\9.0\Source Control\UncontrolledInMemoryEditDialogSuppressed
This still won't work completely. What you then have to do is set your Source Control for that project to Visual Source Safe. (<-- this is the step I'm assuming you won't like.)
Then restart VS2k8.
At this point if you set one of your files to read-only, you will see that Visual Studio will not let you edit this file at all. When you try, it plays your computer's exception music.
Now, to make your files read-only when you run the app, set a post-build process to do this. That's easy.
Harder, is to set them back to writable once your app finishes running. The simplest solution is probably a batch file shortcut.