25 Feet Below the Surface

Architecture, Paradigm & Solutions

The Breakpoint will not currently be hit. No symbols have been loaded for this document.

The Breakpoint will not currently be hit. No symbols have been loaded for this document.

  • Comments 2

Recently one of the Engineers on my team ran into a strange problem. Well at least it looked strange when I went by to look at it. So this Support Engineer (prashant) was working with a customer who wanted to setup debugging through Visual Studio 2005 on his local box.

The problem was that we could set a breakpoint in Visual Studio 2005 but for whatever reason, the breakpoint was not getting hit and the page would load as if we had done a "Run without debugging".

So prashant was pinging me on Instant Messenger and I was throwing out a lot of support articles and voice columns etc out to him and saying "Go check this", "Go Check that" etc and he was getting no where towards a resolution. The message that the customer was seeing in Visual Studio 2005 looked like the following.

 

 

Usually when we see such a problem, the first thing we do is to delete all the files in the "Temporary ASP.NET Files folder" restart all IIS Services and then close Visual Studio 2005 (just to be on the safe side) and re-open the project. But this wasn't helping for this customer.

Surprisingly when we created a brand new website it still showed the same problem. Now if we reflect on this, the symbols or PDB files are automatically generated as soon as you Build the project taking care that the debug attribute is set to "true" in the web.config file. Now if I do an F5 in VS 2005 and do not have debug set to true, it will automatically prompt me about that.

So I asked prashant if the customer was seeing any PDB files in this folder and he replied in negative, which confused me a bit more. Well there may be other settings in the Visual Studio environment I wasn't aware of. So I went over and got on the call with the customer.

The next thing I did was to verify each and every setting in my VS 2005, Tools-->options against the customers settings, they were all the same.

Checking the Output window in VS 2005 I could see the following as a part of the output.


'aspnet_wp.exe' (Managed): Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\nestedmasterpages\63e2be96\b8e0b1a0\App_Web_o61dj5fa.dll', No symbols loaded.



I went and looked at the output in the temporary ASP.NET files folder and surprisingly there were no PDB files generated and what was more interesting was that the output had files in it which looked as if the DEBUG attribute was never set to true!!!

Normally when we have the DEBUG attribute set to true, we will have a lot of extra files in there like for example the .cs file, .pdb file, .cmdline, .err and .out. Each of them has its own significance around it, but in this case the only files in there was the .compiled, the .dll, hash.web and the .ccu.

By this time I started loosing some focus, since I wasn't sure what to make of it, theoretically when we have the debug set to true in web.config it will override all other settings, but this was like Crazy!!! I started getting Filemon logs to see if we were even loading the web.config file and what not.

Filemon did show me that the .cs file and .pdb files were getting created but devenv.exe (process for VS 2005) was going and deleting them.

While I was troubleshooting the problem I was also explaining as I went along about the temporary files and what creates them and what kind of information is in there. Finally the customer said "you know what, I was reading up on a Scott Guthrie's blog and I found something there, which may be related"

He then told me about the retail = "true" setting. you can read all about it at the following link

http://weblogs.asp.net/scottgu/archive/2006/04/11/Don_1920_t-run-production-ASP.NET-Applications-with-debug_3D001D20_true_1D20_-enabled.aspx

 

So if you look at the blog above, if you set the <deployment retail = "true" /> in the machine.config file you will disable the <compilation debug = "true" /> switch for every web application on the server.

It looks like the customer was recently planning to do this on one of there production boxes and probably tested this locally and forgot to turn it back to false and that's what was causing the whole problem.

Comments
Page 1 of 1 (2 items)