Read last executed SQL statement from a memory dump


In this post I’m going to show you how to diagnose SQL exceptions using memory dumps. Imagine you have a web application deployed on a production server. Your application is using Elmah configured to log all exceptions to a dedicated table. One day you receive information that users are unable to make orders and in the Elmah log there are lots of SqlTypeExceptions:

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.
 at System.Data.SqlClient.TdsParser.TdsExecuteRPC(_SqlRPC[] rpcArray, Int32 timeout, Boolean inSchema, SqlNotificationRequest notificationRequest, TdsParserStateObject stateObj, Boolean isCommandProc, Boolean sync, TaskCompletionSource`1 completion, Int32 startRpc, Int32 startParam)
 at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite)
 at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite)
...

No more information available. If you are using NHibernate you may turn on SQL logging but, if you have thousands of users, this will have a negative impact on the application responsiveness. Another idea might be to use ADO.NET ETW logs – even though this way we will minimize the performance drop, it’s still not a perfect solution. ETW logs weigh hundreds of MB and contain a tremendous amount of information, which you need to filter and analyze. I plan to write about this type of logging in the future. For now, let’s take a third approach: create a production memory dump when the application breaks and analyze it locally in the debugger.
Continue reading

Forget PowerPoint – make a slideshow in… a debugger :)


Few days ago I had a presentation in the Warsaw .NET Group about PDB files. To make the slideshow more attractive (or rather original:)) I decided to replace the PowerPoint with something more connected with the subject, such as… the Visual Studio debugger. The only question was how to actually achieve this. The idea grew in my head after reading a brilliant Mike Stall’s post about debugging dynamically generated code. Mike shows in it how to emit sequence points for a text file of your choice and so bind this file with the generated MSIL. If done correctly, the debugger will load the text file, allowing you to step through its content and at the same time execute the emitted MSIL. So what if we could use the presentation table of contents as our source file and for each title (line of the table of contents) emit MSIL which will present a corresponding slide in the console window? This will actually make the debugger play the role of the PowerPoint:)

Continue reading

Take advantage of Reference Paths in Visual Studio and debug locally referenced libraries


Are you using NHibernate or other open-source library in your project? I’m pretty sure that you are. Have you ever wondered what’s happening “under the cover” when you call Session.Get or perform a query? You probably did. The problem is that usually all the external assemblies are stored in one directory (libs, packages, reflibs etc.) with no symbol files or sources. In this post I would like to show you how you can benefit from project’s ReferencePath property and debug the source code of your libraries at any time you want.
Continue reading

Remote debugging with Visual Studio 2010


I’ve recently needed to remotely debug a .net desktop application with Visual Studio 2010. After having read the MSDN documentation on this subject I still missed some information. I hope that this post will fill some of these gaps and will help you configure and run the remote debugging tools.
Continue reading

Visual Studio source server cache


Have you ever wondered where Visual Studio 2008/2010 stores the source files that it downloads from the source server? By default they are put in your home directory under Local Settings\Applications Data\SourceServer. If you are using two different debuggers or you have more than one user using your machine you probably would like to change this location. Unfortunately there is no way to do that through the options dialog. You are left with two options described below:

  • through registry – by changing a value of the SourceServerExtractToDirectory key in the HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\Debugger\ branch
  • through options file – locate your Visual Studio settings file (its path should be displayed under Tools->Options->Import and Export Settings), then a tag: <PropertyValue name=”SourceServerExtractToDirectory”> and change it’s value to your desired cache directory

If you know any other way of changing this Visual Studio setting, please describe it in the comment.