Martin Kulov's Blog

There are known problems in Visual Studio 2008 SP1 related to breakpoints and debugging experience with multithreaded applications. Since these days almost everything that you write is multithreaded app, I would recommend you to install the hotfix from MSDN Code Gallery.

Here are the possible symptoms:

• Breakpoints in parallelized loops are eventually ignored after multiple hits
• Stopping and starting threads causes breakpoints to be missed
• Visual Studio may crash when you debug multiple processes at the same time
• Stepping over a disabled breakpoint when you debug a native application turns into a "go"
• Stepping when you debug a managed multithreaded application can randomly turn into a "go"
• Visual Studio crashes when you use the "Step Into" command to start an MPI program
• Running the "Step Over" command while you are debugging multiple processes causes a deadlock
• Disabled breakpoints are not visible after you install Visual Studio 2008 Service Pack 1

Labels: Debugging, Tools and Tips

Labels: Debugging, Events

Yesterday I bumped into a strange Operation Aborted error. I really did not where to start looking for this error. I tried running the web site with first chance exceptions [1][2][3] turned on, running a script debugger and HTML validator but without any luck. Seems that the error is IE app related and you have to debug the IE process itself in order to find it. I did not want to go into that muddy waters so I run a more deeper search in google and I found the reason.

One of our third party components was generating HTML on the fly while the DOM is still being created. In short the problem is that scripts that are not direct child of BODY cannot modify the BODY element while the DOM is still being created.

You can find detailed explanation on the great Infinities Loop blog and in BUG: Error message when you visit a Web page or interact with a Web application in Internet Explorer: "Operation aborted" (KB 927917).

One possible solution is to put a setTimeout call for about 0.5s which calls your script at the time when (hopefully) DOM will be ready. I would not recommend this approach in general though.

For some reason the script which was marked with DEFER attribute, obviously was not deferred until the page is loaded. The problem was detected while running IE7.

[1] First and second chance exception handling (KB 105675)

[2] How to Stop on First Chance Exceptions - Visual Studio .NET 2003

[3] Demystifying first-chance exceptions (Part 1)

Labels: Debugging, Tools and Tips

I am going to speak this Saturday at a brand new conference at Warsaw, Poland called Communities to Communities 2008 - " the first ever countrywide IT conference in Poland organized by community of Microsoft .NET and SQL Server professionals and geeks". I am going to talk about Debugging and Crash Dump Analysis of ASP.NET Web Sites where I will show real life examples how WinDbg saved my poor soul a number of times. WinDbg and related debugging techniques are something that every single production manager should know and shouldn't be scared to run and try. I will also show how you can analyze a sample stack trace and track down a specific value in stack. If you are in the area, I would love to see you there and talk to you.

Labels: Debugging, Events

John Robbins is the ultimate debugging hero for me.

Read to what John Robbins says about the new released .NET Framework Source Code:

1. If you've been downloading your symbols with the Microsoft Symbol Server, make sure to delete your cache directory before you start downloading from the new symbol location.
2. Shawn says you'll want to check the "Search the above locations only when symbols are loaded manually" in the Options dialog, Debugging, Symbols node. Personally, I think it's much better to leave that unchecked so that you get the symbols and source downloaded automatically. Yes, there will be some slowdowns on the download, but by getting the symbols and source every time you access the item, you'll fill up the cache quicker.
3. If you're having some trouble getting everything to work, turn on the source server diagnostic messages in the Options dialog, Debugging, General node:

Also, as you are loading downloading source files by double clicking on them in the call stack window, you can see the path reference location in the status bar.

1. To get both the new Reference Symbol Server and Microsoft Symbol Server set in your _NT_SYMBOL_PATH environment variable to the following:
   UPDATE: This is the correct syntax
   SRV*c:\symbols*http://referencesource.microsoft.com/symbols;
   SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
2. For you advanced hackers out there, I tried like crazy to get SYMCHK and PDBSTR to work for pre-downloading and bulk source extraction working, but with no luck at all. It appears that the WinDBG tools don't have support for source servers that use http downloads, but the QFE added that support to Visual Studio 2008. (See my article if you don't know what I'm talking about.)

Read original post.

Labels: .NET, Debugging, Tools and Tips