I am trying to debug a project, suddenly I'm running into an issue where enumerating any object collections results in a timeout if I try to view it.
If I run the program normally I have no issues. If I try to view any collection, such as a list, I get a timeout error and the whole thing bombs out.
I thought something might be going on with one of my more complex collections so I tried creating just a normal list of strings as follows...
List<string> blah = new List<string>{"fsdf","fsdg","Gt","gsersg","ser","gersgxdrsd"};
The same thing happens. I can hover over the object, I can even see the object count, however if I view the collection it dies.
I've ensured that the project/class library is in debug mode, disabled all extensions, restarted the system, tried percusive maintnence - nothing has worked.
Does anyone have any ideas? I'm completely losing my mind here.
I should also mention that this is a web application, I didn't notice before but a w3wp debug window pops up after I stop debugging. Sorry to leave out important info - was too frustrated to think straight when I wrote the post. I can still execute my code normally, and while debugging. I can examine all other objects without issue, it is only looking at collections in the watch window (or by hovering) that breaks.
Have a look at How to correctly debug web applications on local IIS 7.5 with VS 2010 Beta2?
Related
I have an puzzling problem. I have a new ASP.NET web application in VS2005 that runs fairly well, but I am having a problem and would like to set a break point to see what is going on. I have compiled the project in Debug mode. I have debug=true set in the web.config. But it appears that the IDE is not attaching to the process at all. Have I overlooked something? I am using the development server and not IIS. This has never been a problem in the past, but is this time.
Have I overlooked anything? Thanks for any help.
Rob
I had this issue a while back with VS2005. I don't remember where I got the following instructions from (copied them to a file which I'm now copying to you) but doing the following steps worked for me. It has something to do with IE8 attaching itself to multiple processes and messing up the debugger. Word of warning, this has you editing the registry, so use at your own risk / take all your normal precautions, etc.
Open RegEdit
Go to HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet
Explorer -> Main
Add a dword under this key called TabProcGrowth
Set TabProcGrowth to 0
If you run into the same problem on
Vista or newer, you will also need to
turn off protected mode.
Please note also that I was/am running XP at the time, so I did not have to use the "Vista or newer" clause there. No idea if that has any adverse effects either.
Sorry if I am stating the obvious, but you need to Start Debugging <F5> rather than just running the executable after compiling. Are you doing this?
If you don't hit the breakpoint, you are either not debugging (F5) or your code isn't reached at all. If you want to know which of the two is happening you can throw an exception right at the code where your breakpoint is. If your application is failing at the exception, you know you are not running it with the debugger. If it doesn't fail at the exception you are simply not reaching that piece of code and you will have to look harder for which code you are actually running.
throw new Exception("if I see this exception, I am not running the debugger");
Or maybe you are running two instances of the development server. I've had that sometimes. Look in the Windows system tray for the icon. If you see two (or more) you can right click to stop them and restart debugging.
I'm having a simple ASP.NET application hosted on my local IIS6, under Vista.
It contains a button that when I click I execute a piece of code for recognizing the text in a WAV file (using the System.Speach.Recognition.SpeechRecognition class) and display the text in a label.
The code works great on a desktop application, and it almost works on the web one... I say almost, because if I debug, I can see that the recognizer returns the correct text from the WAV, I can see that I am finishing the handler for the button click with no error, but nothing gets displayed in my page, and the page appears like loading... it's hanging, or something... No errors, no timeout, nothing. Just loading...
I don't know if this detail helps, but in order to make the piece of code that was already working on the desktop application work on the web application, I had to set the identity of the ApplicationPool of my application to LocalSystem (security breach, I know). Otherwise, I would have received a Access Denied error (0x80070005(E_ACCESSDENIED)).
Do you have any ideea why the call hangs like that? I'm fighting with this for more than two days, time pressures me, and I have no clue... Any help is really welcomed!
Thanks!
After another one week of stuglles, I found an overcome to the problem. I'm posting this just so other that might have this problem find the solution faster.
The solution was to call the method for making the speech recognition on a different thread. I think this forced the release of all resources in that thread after the recognition ended.
I cannot make any sense why this even happened on the first place (I used using blocks and I closed and disposed all the object in all the imagining ways), but I suspected to be a memory release problem...
Anyway, a very simple call on another thread fix it!
I have three Silverlight 3 applications in the same solution. In my asp.net hosting project I have a seperate page for all three projects. When I navigate between the pages, the only Silverlight breakpoints that get hit are the ones the initial page I load.
This problem has only started recently. I used to be able to debug between all silverlight projects at the same time. Any ideas? I have deleted the ClientBin folder, I have deleted all files and re-retrieved from source control. Nothing seems to be working.
"The problem has only started recently". What changed? Here are some guesses:-
You upgraded to Windows 7
You installed some more memory
Some other memory guzzling app is no longer running when you are testing.
By default IE8 will run multiple processes at least 2. One for the browser frame and one for the content of the intial tab. As you open more windows and tabs IE may add new processes to the set it is currently using.
When you debug VS will launch an new IE8 session and will attach to the process handling the content of the single tab that is open, (it doesn't bother attaching to the parent frame process). However as you navigate about your application IE8 will start new process that VS won't be attached to. This forces you to open the Attach to Process dialog and do it manually.
You can control this IE8 feature (called BTW LCIE, Loosely Coupled IE) from the Registry.
In the Key HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main add a new DWORD value TabProcGrowth. Set its value to 1. Now IE8 will only ever create 2 processes per session one for the frame and one for all the tab and window contents which is the one the VS will attach to.
This perhaps is a bit draconian if you also use IE8 as your general browser. One option is to leave IE8 for test purposes and use another browser for general browsing. Another option is a variation of the above. Instead of creating TabProcGrowth as a DWORD create it as a string type instead and set is value to "small". In this mode IE8 is much less aggressive in the number of processes it will open. Of course you could create a couple of scripts to create and delete the registry entry.
Note without the registry entry IE8 uses its own hueristics that depends on available memory etc to determine if a new process is warrented or not. This might explain why in the past your debugging worked and that for apparently no reason it stopped working.
Here was the issue:
One of my child windows had a Silverlight that calling a .Net Ria Service. The service call ended in an error.
The next time several I debugged, the debugger did not attach to the child windows. I had to attach to the child windows manually.
I fixed the Ria Service call so that it did not end in an error. And had to manually attach to the child windows in that debugging session. However in subsequent debugging sessions, the debugger automatically attached.
I tried breaking the Ria Service call and I had to manually attache again. What is a little weird is that closing Visual Studio and even rebooting the machine does not make Visual Studio automatically attach again. You have to have a debugging session where the child window make a sucessful call to a Ria Service to fix it.
NOTE:
The RIA error that was breaking my debugger was caused by a misspelled include in the domain query (ie...
return Context.SOME_ENTITY.Include("Misspelled_Association_Property");
) not all RIA exceptions cause this problem.
My scenario has a number of specific cases that I will go over. I don't have all the things handy to test a more general scenario, but I will when I finish my project unless someone does this first.
Here is what I have:
I am using the a LinqToEntitiesDomainService from the July 2009 Preview release of .Net RIA Services.
To complicate things a little more, since my application is using an Oracle backend, I am using DevArt's dotConnect Entities provider as the EntityFramework model for my domain service.
When I get time, I will try this on the Nov 2009 RIA and a standard SQL backend and EF to see if I still have the same issue. If this is the case I will report it to Microsoft as a visual studio bug.
On my work computer, debugging in Visual Studio 2008 (SP1) seems to work somewhat different from what I'm used to. I have two problems that might or might not be related.
First problem:
When I'm running a web application in debug mode, and an unhandled exception occurs, I get a Yellow Screen of Death immediately. Normally my code just breaks at the line throwing the exception, allowing me to inspect the state of the program.
For some reason, the only way I can do that on my work PC is to set a breakpoint on the line that threw the exception, and repeat what I did. It's been annoying me for a couple of days now, but I have no idea what could cause this. Any ideas?
Second problem
The WCF webservices used in the site I'm debugging behave a little odd when it comes to debugging as well. Most of the time, setting a breakpoint in the service won't have any effect when it executes that code. At first, I figured I had to attach to the wcfhost process, but that isn't it. When I put a breakpoint on the line where it calls the service, and use F11 to step into the method call, I do end up in the service's code and I can debug all I want.
Why would stepping into work, while breakpoints get ignored? Is there a way to change this behavior?
For the 1st problem:
In Visual Studio go to Debug/Exceptions
You should see three columns in the list: "Name" (type of exceptions), "Thrown", "User-handled"
In the "User-handled" column you have to activate the checkbox for "Common Language Runtime Exceptions".
Note, if you shouldn't see the "User-handled" column, go to Tools/Options, then click on "Debugging" in the tree and on the list activate "Enable Just My Code (Managed only)". Then the column "User-handled" should be visible in the other dialog and you can activate the according checkbox.
For the 2nd problem:
It seems to me as if I have experienced a similar problem. I guess you have to set the breakpoint there, because the WCF service runs on a separate "webserver" (your local VS webserver). Therefore it isn't like a normal method call within your same application and therefore you have to set the breakpoint on the WCF method that gets called. I always did it this way and it worked perfectly for me.
How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.