10101010101001

0101010101001

Archive for the ‘Tools’ Category

Debugging .Net Framework source stepping problems using dia2dump

with 2 comments

So you are trying to step into .net framework source code.
You configured debugging options, triple-checked everything, consulted this comprehensive FAQ here: http://blogs.msdn.com/b/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx.
Still nothing seems to work.

You are not alone :(
The most likely cause is that Microsoft has released some patches to the .net framework, and didn’t publish pdbs that you could use for stepping into .net framework source code.
So supposing that you are trying to debug DateTime.Now.
First look on where the pdb-file downloaded from Microsoft Symbol Server is located on your computer, by right clicking in the Call-Stack -> Symbol Load Information:
pdbloadinfo

Now we’ll look inside this pdb file using dia2dump which is a tool that comes with visual studio at: c:\Program Files (x86)\Microsoft Visual Studio 10.0\DIA SDK\Samples\DIA2Dump\

It’s not compiled by default, so you’ll have to open it’s sln and compile it. Fortunately it’s just a small C++ proj, and compiles easily. (Just press compile).
After compiling you should see it at c:\Program Files (x86)\Microsoft Visual Studio 10.0\DIA SDK\Samples\DIA2Dump\Debug\.
To look inside a pdb file you just open a command prompt and write: dia2dump.exe xxx.pdb >xxx.txt . This will write the contents of the pdb inside a xxx.txt.

So if we run dia2dump on the mscorlib.pdb file which was downloaded we can see that it doesn’t contain any source files information or start /end addresses like the mscorlib.pdb you get from: http://referencesource.microsoft.com/netframework.aspx and it’s ~300 KB vs 10 MB.
Now I’m no pdb file contents expert, since the format of the pdb keeps changing and there’s no public specification according to microsoft (you can read more about it here: http://msdn.microsoft.com/en-us/library/x93ctkx8%28v=VS.80%29.aspx)
But the fact that there’s no addresses and source code mappings does ring a bell to me that the pdb is not one that we could use for .net framework source code stepping purposes.

So how do we make it work?
My first idea was of using that “Browse to source” option in visual studio 2010, and browse to .net framework source code you have downloaded manually from referencesource.microsoft.com. But after looking at the information inside the pdb, or rather the lack of it, it’s now clear why it’s always grayed out.

So one solution is to use Reflector Pro, which is commercial, and use it’s runtime debugging feature to step into microsoft .net framework source code.
This is not an ideal solution (especially because of the optimized code), and I just don’t understand why Microsoft doesn’t publish automatically source code according to their latest hotfixes/patches of the .net framework :(
I mean, I need to step into .net framework because I’m having problems today, not in two months when they decide to actually publish it. What am I supposed to do? Disable windows update so I don’t install any hotfixes? :(
This might be a second solution: Just have a virtual machine with visual studio installed, and a .net framework version which has .net framework source stepping support. Then disable any updates on that virtual machine and do your debugging there. (Really painfull, I know)

Advertisements

Written by Liviu Trifoi

May 17, 2011 at 8:06 pm

Using Process Monitor to debug applications

leave a comment »

Every once in a while there comes a bug that requires the use of Process Monitor
Process monitor is great but sometimes it is difficult to correlate its event stream with the source code you are debugging.

Using it for quite some time, I don’t really read it’s help anymore, but accidentally I’ve looked into it recently and was pleasantly surprised to see  that it now supports injecting debug messages into it’s event stream using an API and there’s even a managed wrapper for this (read diagnostic tracing process monitor)
A few of my colleagues asked me for scenarios in which to use it, so I’ll describe a few from my personal experience.

I mainly used it for debugging bugs that involve the file system or registry in some way.

Example 1:

I was maintaining a real-time legacy system that was doing a series of processing on xml files. Each processing involved creating  a temporary file in a certain directory. The problem was that sometimes certain files were lost.

Code looked similar to this:

string filename = string.Format(“{0}-{1}.xml”,
DateTime.Now.ToString(“yyyy-MM-dd-HH-mm”), Environment.TickCount);
filename = Path.Combine(dir, filename);
// synchronize access to file
lock (m_cs.MainAppDomain)
{
	using (StreamWriter sw = File.CreateText(filename))
	{
		sw.Write(content);
		sw.Close();
	}
}

Can you spot the problem? I stepped through the code many times, and I wasn’t able to reproduce the bug.

After using Process Monitor I was able to spot it: the unique filename made from the number of miliseconds since the system has started is not really unique. In some cases more than 1 file/milisecond can be created, in which case the second file overwrites the first one.

Example 2:

I had to do production debugging on a system accessible via Remote Desktop (via a special Remote Desktop infrastructure), but located behind an inaccessible subnet. So remote debugging was out of the question. It wouldn’t have helped anyway for this particular bug.

I had a piece of code that was installing an X.509 Certificate which was working under one Administrator user, but wasn’t working under another Administrator user.

The error I was receiving was “File not found exception” (the filename not being found was an empty string). Exception stacktrace was ending in an internal CAPICOM library (windows library).

At first I thought it was a security issue, so I enabled Windows security auditing but no security events were being logged, so this wasn’t a security issue.

So what I did was: take the output of process monitor when code was running fine and take the output of process monitor when the code was not working.

I compared these two and it revealed that, when it was not working, code didn’t found an AppData registry values in
HKEY_USERS\S-1-5-21-218976661-61539242-33973980-1010\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\

AppData normally points to the Application Data environment folder and should have been there. Seems somebody corrupted the registry, because lots of other shell folder values were missing too and is used by CAPICOM to locate the physical certificate store when installing a new certificate.

So I manually re-created the missing values by looking at a working system, and everything worked.

So registry corruption is another good scenario where you can use it.

Written by Liviu Trifoi

June 21, 2010 at 5:42 pm