PFE - Developer Notes for the Field : Zach

How do I dump out a string?

zakramer — Thu, 12 Nov 2009 17:58:00 GMT

The topic came up a while back on one of our aliases – How can I dump out a string?

There are a lot of ways do this in the debugger and there are also debugger extensions that will help out with. What most people in WinDBG do is us the “du” command for Unicode strings and “da” for ASCII strings. However this has a problem in that output looks like:

00000001`40234dd8 "Server=com-appdb-01\moss1;Databa"
00000001`40234e18 "se=SharedServices2_55;Trusted_Co"
00000001`40234e58 "nnection=yes;App=Windows SharePo"
00000001`40234e98 "int Services;Timeout=15"

You cannot easily cut and paste this into other places. You have the addresses and such. Also, this only handles a few lines. If you check out the help for the du commands there is /c switch which says only dump the characters instead of all the characters. You would end up with a command like - “du /c”. To take it one step further you can actually create an alias:

as !ds du /c 100 c+

Then all you have to do is - !ds <address to String object>

So this combines both aliases and come special switches.

Thanks,

Zach

What does High Performance Mean?

zakramer — Tue, 10 Nov 2009 17:35:00 GMT

Over my years in PFE and Microsoft as a whole I have worked on some REALLY cool websites and applications that are used around the world and drive a lot of business. Getting work on these cool projects is one of the main reasons that I love what I do. Getting to see what cool problems people are solving with Microsoft technology. One of those cases was highlighted a few months back on Channel9!

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Steve-Michelotti-of-eimagination-on-High-Performance-Web-Solutions/

Steve Michelotti does a great job of explaining some of the stuff that we did and what the applications look like. So check it out!

Thanks,

Zach

Passing a Managed Function Pointer to Unmanaged Code

zakramer — Sun, 08 Nov 2009 22:27:00 GMT

I was working with a customer a while back and they had a situation where they wanted to be able to register a managed callback function with a native API. This is not a big problem and the sample that I extended did this already. The question that arose was – How do I pass a managed object to the native API so that it can pass that object to the callback function. Then I need to be able to determine the type of the managed object because it is possible that any number of objects could get passed to this call back function. I took the code sample that is provided on MSDN and extended it a bit to handle this. Here is the original sample - http://msdn.microsoft.com/en-us/library/367eeye0.aspx

The first commend here is that this is some DANGEROUS territory. It is really easy to corrupt things and get mess up. For those that are used to manage code this is very much C++ territory where you have all the power and with that comes all of the rope that you need to hang your self.

As I mentioned about the customer wanted to be able to pass different types of objects in the lpUserData so the callback can handle different types of data. So the way to do this is with a GCHandle. Basically this gives you a native handle the object. You pass that around on the native size and when it arrives on the managed side you can “trade it in” for the managed object.

So let’s say you have some sort of managed class. In this case I called it “callbackData” and you want to pass it off.

callbackData^ cd = gcnew callbackData();

First you need to get a “pointer” to the object that can be passed off:

GCHandle gch2 = GCHandle::Alloc(cd);

IntPtr ip2 = GCHandle::ToIntPtr(gch2);

int obj = ip2.ToInt32();

You need to keep the GCHandle around so you can free it up later. It is very possible to leak GCHandles. In addition GCHandles are roots to CLR objects and therefore you are rooting any memory referenced by the object you have the GCHandle for so the GC will not release any of that memory. This however is not as bad as pinning the memory. The GCHandle is a reference to the object that can be used later to retrieve the address of the actual object when needed.

From the GCHandle you can convert that to a an IntPtr. Once you have an Int from the IntPtr that you can pass around to the lpUserData parameter. You could also just directly pass the IntPtr but I just wanted to demonstrate taking it all the way down to the int.

Then you can pass that value as part of an LPARAM or whatever you want to the native code.

int answer = TakesCallback(cb, 243, 257, obj);

That will get passed to your callback that uses your delegate to call into your managed function. The native code might do something simple like this:

typedef int (__stdcall *ANSWERCB)(int, int, int);

static ANSWERCB cb;

int TakesCallback(ANSWERCB fp, int n, int m, int ptr) {

   cb = fp;

   if (cb) {

      printf_s("[unmanaged] got callback address (%d), calling it...\n", cb);

      return cb(n, m, ptr);

   printf_s("[unmanaged] unregistering callback");

   return 0;

In inside your callback function you simply get back an object:

public delegate int GetTheAnswerDelegate(int, int, int);

int GetNumber(int n, int m, int ptr) {

   Console::WriteLine("[managed] callback!");

   static int x = 0;

   ++x;

   IntPtr ip2(ptr);

   GCHandle val = GCHandle::FromIntPtr(ip2);

   System::Object ^obj = val.Target;

   Console::WriteLine("Type - " + obj->GetType()->ToString() );

   return n + m + x;

Once you have the object you can cast it or do whatever you need to move forward. This approach allows you to bridge across the managed and native world when you have a native function that makes a callback. I will attach a complete sample for you to play with if you interested and let me know if there are any questions. There are other ways to approach this I am sure but this seemed to work pretty well and as long as you manage you rGCHandles and callback references you should be good to go!

Thanks,

Zach

REFERENCES

GCHandle.Target - http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.gchandle.target.aspx
How to: Marshal Callbacks and Delegates Using C++ Interop - http://msdn.microsoft.com/en-us/library/367eeye0.aspx

IIS and Hyper-V

zakramer — Fri, 04 Sep 2009 00:01:00 GMT

The other day the topic came up about best practices with IIS and Hyper-V. One of our team mates pointed out the following links which are an interesting read:

http://www.virtualization.info/2008/05/microsoft-migrates-msdn-and-technet-on.html

http://blogs.iis.net/mailant/archive/2008/05/29/technet-msdn-iis7-front-end-servers-running-100-virtualized-using-hyper-v.aspx

These go over the migration of MSDN/TechNet infrastructure over to Hyper-V. Cool stuff!

Windows Server 2003 Service Pack 2 and 24-bit Color TS Connections

zakramer — Mon, 23 Mar 2009 22:13:34 GMT

Okay this is a really weird one! When you install Service Pack 2 on Windows Server 2003 you can no longer connect using MSTSC via Terminal Services (TS)/Remote Desktop(RDP) with a 24-bit color setting. For the customer I was working with this meant that the applications they are hosting on those servers did not look good at all over this down graded connection. For them it meant a blocker to upgrading to SP2. This has gotten more important recently because Service Pack 1 for Windows Server 2003 is about to be out of support.

So a hunt ensued for how to get this working. It turns out that there was a bug in Service Pack 2 that disable some of these higher bit rates. The bug was corrected in KB – 942610 although this was not apparent that it applied to my problem since the description was different. However it turns out that the same underlying issue was causing both problems. A couple of other changes needed to happen and then everything was working. Here are the steps that I came up with to take a Win2K3 SP2 box and enable 24-bit Color Connections:

Install the following hotfix - http://support.microsoft.com/kb/942610
Update the following registry key to enable the fix:

Registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
Registry entry: AllowHigherColorDepth
Type: REG_DWORD
Value: 1

Note that I found the hotfix does add this registry key but it had the value set to 0 so it disabled the fix. I had to change it to 1. Also, typical warnings about editing the registry apply. If you go crazy you can toast your box so back up stuff first! For those that are sticklers here is the official warning:

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:

322756 How to back up and restore the registry in Windows

Ensure the TS box is excepting 24-bit connections

Go to Start->Run
Type “tscc.msc” and hit enter
Click “Connections”
Right click on “Rdp-tcp” and select properties
Click the “Client Settings” tab
Ensure that “Limit Maximum Color Depth” is set to 24-bit

Restart the server to ensure everything is set.

Hope this helps!

Thanks,
Zach

Combining NetMon CAP Files

zakramer — Sat, 14 Mar 2009 02:37:37 GMT

Today I was working on a problem that we thought was network related. That meant it was time to try out some of those NetMon skills. NetMon is the Microsoft Network Packet Capture and Analysis tool that is similar to WireShark/ethereal and can the current 3.2 version can be download for free from here - http://www.microsoft.com/downloads/details.aspx?FamilyID=f4db40af-1e08-4a21-a26b-ec2f4dc4190d&DisplayLang=en

For the longest time I am a lot of my colleagues used WireShark/ethereal to do network captures. However Netmon has come a long way and I really am a big fan of it now.

Back to my problem today. We were dealing with a Web Server that has a decent amount of traffic and problem that occurred intermittently. I first started just capturing with the UI but quickly saw the memory grow and the box slow down a bit. I did not need to see the traffic going by I just needed to do a capture. This lead me to the NMCAP tool that ships with NetMon. This is a basic command line tool that allows you do to do captures.

So I started capturing and by default if you use the *.chn extension on the file name you specify it will create 20 MB CAP files with your network data. This as great. I could easily filter out the ones I did not want while I awaited the problem.

Finally the problem reproduced and now I was ready to analyze. I opened the trace closest to when the problem occurred and began working through the trace. I quickly found some conversations that I was interested but – Where was the beginning? Where was the end?

The answer to this – In some of the other traces!

Now I had 3, 4, 5, 6 different traces open and that was no good. I quickly wanted to be able to combine the 6 or 10 traces that I was interested it. I found out that the same NMCAP tool can easily do this. All you have to do is use the /InputCapture param. You end up with a command line like this:

namcap /InputCapture Trace1.cap Trace2.cap Trace3.cap /capture /file Trace.cap:500M

This was a life saver so I thought I would pass it along! Enjoy and have a great weekend.

Thanks,

Zach

.NET Framework 2.0 Service Pack 2

zakramer — Tue, 27 Jan 2009 09:44:50 GMT

I have worked with several customers that want .NET Framework 2.0 SP2 but do not want to either require their customers to install .NET Framework 3.5 w/ SP1 or do not want to do it themselves.

Well due to the way it was packaged up until this point that was the only way to get it. However ask of just the other week they finally released a standalone installer for .NET Framework 2.0 Service Pack 2:

http://www.microsoft.com/downloads/details.aspx?FamilyID=5b2c0358-915b-4eb5-9b1d-10e506da9d0f&displaylang=en

This is great news and will make the deployment a bit easier for people on Windows XP and Windows Server 2003. For Vista and Windows Server 2008 you still have to get .NET Framework 3.5 SP1 installed to get .NET Framework 2.0 SP2.

Finally, make sure that you also install the following update - http://support.microsoft.com/kb/959209. This update fixes some of the known issues that have been found with the service packs since their release.

Have a great day and happy installing!

Zach

Windows Error Reporting (WER) Web Service

zakramer — Wed, 03 Dec 2008 18:11:00 GMT

I have long thought that one of the coolest features of the Windows OS for developers is the Windows Error Reporting infrastructure (with roots in Dr. Watson). You can have your application upload dumps to the WinQual portal – http://winqual.microsoft.com.

One of the problems though has always been getting those dumps off of the WER site. Before it was a manual process of going to the WinQual website and download CAB files. Well I found out today that the WER team recently released a Web Service that allows you to pull them down automatically. They have also released some sample applications to get you started:

Windows Error Reporting on CodePlex - http://www.codeplex.com/wer

This opens up all sorts of possibilities such as automatically creating bugs in your bug DB (TFS hopefully!) in response to a new dump file getting uploaded so that someone on your team can take a look.

Finally the WER team has a blog up and running (http://blogs.msdn.com/wer) and their first entry discusses this and has some demo videos from PDC:

http://blogs.msdn.com/wer/archive/2008/11/25/windows-error-reporting-wer-blog.aspx

Enjoy!

Zach

Best Practice - in ASPNET.CONFIG

zakramer — Wed, 26 Nov 2008 06:23:00 GMT

Best Practice Recommendation

Add the following line to your ASPNET.CONFIG or APP.CONFIG file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

Note the ASPNET.CONFIG file is located in Framework Directory for the version of the Framework you are using. For example for a 64-bit ASP.NET application it would be:

c:\Windows\Microsoft.NET\Framework64\v2.0.50727

For a 32-bit application it would be:

c:\Windows\Microsoft.NET\Framework\v2.0.50727

Details

I have seen this a bunch of times while onsite. The problem goes something like this:

When I restart my ASP.NET application the initial page load is very slow. Sometimes upwards of 30+ seconds.

Many people just blame this on “.NET Startup” costs but there is no out of the box reason that an ASP.NET application should take that long to load. Some applications do work on startup which can cause a startup slow down but there are other things that cause slow downs. A common cause that I have seen often recently is Certificate Revocation List (CRL) checking when generating Publisher Evidence for Code Access Security (CAS).

A little background – CAS is feature in .NET that allows you to have more granular control over what code can execute in your process. Basically there are 3 parts:

Evidence – Information that a module/code presents to the runtime. This can be where the module was loaded from, the hash of the binary, strong name, and importantly for this case the Authenticode signature that identifies a modules publisher.
Permissions Set – Group of Permissions to give code (Access to File System, Access to AD, Access to Registry)
Code Group – The evidence is used to provide membership in a code group. Permission Sets are granted to a code group.

So when a module loads it presents a bunch of evidence to the CLR and the CLR validates it. One type of evidence is the “publisher” of the module. This evidence is validated by looking at the Authenticode signature which involves a Certificate. When validating the Certificate the OS walks the chain of Certificates and tries to download the Certificate Revocation List from a server on the internet. This is where the slowdown occurs.

A lot of servers do not have access to make calls out to internet. It is either explicitly blocked, the server might be on a secure network, or a proxy server might require credentials to gain access to the internet. If the DNS/network returns quickly with a failure the OS check will move on but if the DNS/network is slow or does not respond at all to the request we have to timeout.

This can occur for multiple modules because we create this evidence for each module that is loaded. However if we have looked for a CRL and failed we will not recheck. However different certificates have different CRLs. For instance a VeriSign Certificate may have one CRL URL but a Microsoft Certificate will have a different one.

Since this probe can slow things down it is best to just avoid the probe if you do not need it. For .NET the only reason you would need it is if you are setting Code Access Security based on the module Publisher. Because this can cause potential slow downs and you do not need to occur this penalty you can just disable the generation of the Publisher Evidence when your module is loaded. To disable this use the <generatePublisherEvidence> Application configuration. Just set the enabled property to false and you will avoid all of this.

Now for ASP.NET applications it was not immediately obvious how to do this but it turns out that you cannot add this to an applications Web.Config but you can add it to the ASPNET.CONFIG file in the Framework directory. For other applications just add the attribute to the APP.CONFIG file.

In closing there are several blog entries that do a great job of demonstrating how this will show up in the debugger and other details on CRL issues and workarounds:

We are highlighting this as the first in a series of general best practice recommendations.

NOTE – If you have .NET 2.0 RTM you will need this hotfix - http://support.microsoft.com/default.aspx/kb/936707

Why is my Window Grayed Out?

zakramer — Sat, 15 Nov 2008 03:57:15 GMT

Starting back in Windows 2000, if I recall correctly, the OS added a feature to try and handle unresponsive windows. The idea is that if an application hangs we do not want the window that is associated with that application to block other stuff that the user is trying to do. This feature has been improved through Windows XP and now into Vista. The feature is not pretty good.

When the OS detects that the application is not “responding” to messages it will take control of y

I came across this when working with a customer that has a client side application. It is single threaded for the most part and has a work flow like this:

Start long running Operation
Prevent painting main UI and ignore most input to that region
Update Status Pane via periodic calls to pump messages for that pane
Update full UI after the operation is complete

This is not an uncommon scenario especially for application that have been around for a while. Sometimes it can be very hard to allow the window to paint during some long running applications and while allowing painting is the real answer there are times where this is MUCH easier said than done.

The feature that grays out windows seems to have gotten more aggressive in Windows Vista to better detect various hang scenarios. This is why this became an issue for them. Basically it was becoming more common to see the graying or “ghosting” of the application’s window. This lead to users thinking the application was dead (the status bar also gets grayed out) and terminating the application. In XP the application would stay there and while the main part of the UI would not respond you could still watch the status bar move.

The question though became what do we do about this? The obvious answer is make the application responsive during the long running application. While this is a goal there is no short term way to do this. We tried a bit to pump more messages but run into a sticky issue – How do I “appear” responsive without actually being responsive. We were basically trying to guess what the OS was looking for and since this can change, as we have seen, this is not reliable.

After some digging I found an interesting API:

DisableProcessWindowGhosting
http://msdn.microsoft.com/en-us/library/ms648415.aspx

Basically this API tells the OS to skip the ghosting even it detects the application as unresponsive. This API will take effect for the run of the application.

The real answer is to fix the application to be responsive as mentioned but that is not always easy so this is a stop gap.

Side note is that when you debug an application the graying or ghosting of the window will not occur. So if you are trying to reproduce make sure that you are running outside of the debugger (this got me when trying to reproduce!)

Hope this helps and have a great weekend!

Zach

$(SolutionDir) and MSBUILD

zakramer — Sat, 27 Sep 2008 01:02:58 GMT

A while back I was working with a customer that was moving from doing all of their builds with the devenv command line to using MSBUILD. However we ran into a hiccup that did not make sense at first. Basically when they tried to build their solution using MSBUILD some of the custom build steps where failing because $(SolutionDir) was not defined.

After thinking about it a bit is became clear that MSBUILD did not define the SolutionBuild property that Visual Studio does. So where did that leave us?

There are a couple of basic approaches:

Create a Custom Action (this would involve Custom Code) that walked up the directory structure and found the SLN file and then used that directory to create the SolutionDir.
Use the command line option /Property:SolutionDir=<sln Dir> to set the value. This way it is controlled in one place.
Change all of the pathing to be relative. In most groups it is relatively infrequent to be moving projects up and down the directory hierarchy.

Just thought I would share incase this comes up for someone else.

Zach

All the Ways to Capture a Dump...

zakramer — Fri, 26 Sep 2008 02:06:58 GMT

Frequently when troubleshooting a problem we capture a memory dump. Memory dumps are a great tool because they are a complete snapshot of what a process is doing at the time the dump is captured. It can be a great forensic tool. There are however an abundance of tools to capture memory dumps (*.dmp). In talking with some new members on our team we were reviewing the dump capture techniques and the benefits/drawbacks. If you have your own thoughts please feel free to comment.

Memory dumps are captured under two categories of problems: The first category is hang dump captured when the application is non-responsive or when you just want a snapshot of the current state of the application. The second category is a crash dump captured when exceptions occur. The debugging purpose, the actions we would instruct the debugger to take would be different for both types of dump.

For hang dumps, we would instruct debugger to attach to the process (if there is no debugger attached) and initiate the dumping immediately. For crash dumps, we would like to attach a debugger to a process first and then set up the instruction to monitor the type of exceptions we are interested in and generate a memory dump upon the exception is raised. We will discuss different ways to generate memory dumps.

First let's take a look at some of more specific scenarios when capturing a dump file (these are grouped for the most part into crash or hang based on what they relate to. There are definitely a lot more variants but these are some basic ones that we can use to compare the different debuggers:

Crash

Create a dump file when an application crashes (an exception has occurred that causes the process to terminate)
Creating a dump file from an application that fails during startup

Hang

Create a dump file when an application hangs (stops responding but does not actually crash)
Creating a dump file while an application is running normally

First Chance - Creating a dump file when an application encounters any exception during the run of the application
Smaller Dump - Shrinking an existing dump file to reduce the amount of information in the dump file

For each of these scenarios how do the debuggers measure up:

Debsuggers/Scenarios	Crash	Hang	First Chance	Smaller Dump
DebugDiag	Yes	Yes	Yes	No
ADPlus	Yes	Yes	Yes	No
CDB/Windbg	Yes	Yes	Yes	Yes
Dr. Watson	Yes	Yes	No	No
UserDump	Yes	Yes	Yes	No
NTSD	Yes	Yes	Yes	Yes
Visual Studio	Yes	Yes	Yes	No
Vista Crash Dump Features	Yes	Yes	No	No

Next let’s take a quick look at how you might use each one and then we will explore a bit more:

	Crash	Hang
ADPlus	Adplus –crash –quiet -o c:\dumps –pn <processname.exe>	adplus -hang -quiet -o c:\dumps -pn <processName.exe
Dr. Watson
CDB and WinDbg	.dump /ma c:\w3wp.dmp	.dump /ma c:\w3wp.dmp
UserDump	see Additional Details below	Userdump PID
DebugDiag	Create a Crash Rule with Wizard	Right click on the process in Processes and select Full Memory Dump.
MiniDumpWriteDump	see Additional Details below	see Additional Details below
Visual Studio	Debug \| Save Dump As...	Debug \| Save Dump As…

There are many ways to capture a memory dump as you can see above. Depending on the nature of the problem, a hang or crash dump can be captured using different tools.

For quick and easy hang dump in production environment that installing tools might be an issue, using NTSD debugger that is distributed with Windows XP/Server 2003 can be easy.

However we frequently recommend to our customers to have the Debugging Tools for Windows and DebugDiag available for their servers. ADPlus has a very low footprint and can be great to capture memory dumps with. DebugDiag is super easy and great for setting up rules to generate dumps. Unless there is a special case DebugDiag is the way to go.

Additional Details

Below are some details for most of the tools that we outlined above and when they might come in handy.

External Tools

DebugDiag.exe from Debug Diagnostic Tool

Where do I get it?

DebugDiag is another free downloadable tool from Microsoft. To download, search for “Debug Diagnostic Tool v1.1” from http://www.microsoft.com/downloads or specifically http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

How do I use it?

Hang - In “Processes” tab, select the process with right mouse, select “Create Full User Dump”. The memory dump will be located at under Logs\Misc folder under the installation folder of DebugDiag.

Crash - Select Rules tab. Click “Add Rule” button. Select “Crash” as the rule type. Click “Next” button. Select target type, for instance, “A Specific Process”. Click “Next” buttons to finish. DebugDiag will monitor crashes and when a memory dump is captured, it will show the number in the “UserDump” column of the Rules panel.

DebugDiag supports multiple crash rules to monitor multiple processes. It also supports many other configurations. For more information, please refer to the help file that is installed with DebugDiag.

Also see the DebugDiag blog for additional information – http://blogs.msdn.com/debugdiag/

Debugging Tools for Windows (WinDBG, CDB, ADPlus)

Where do I get it?

This set of tools is downloadable for free from http://www.microsoft.com/whdc/devtools/debugging/default.mspx

How do I use it?

Assuming it will be installed to C:\Debuggers folder, we will use that folder for examples.

Catch a hang dump using ADPLUS.vbs

Adplus.vbs is a vbsript that makes your life easy to use cdb debugger. To capture a hang dump to c:\dumps folder from a running instance of NOTEPAD.exe that has process ID 1806, type:

C:\debuggers>adplus -hang -quiet -o c:\dumps -p 1806

To capture hang dumps to c:\dumps for all instances of NOTEPAD.exe, type:

C:\debuggers>adplus -hang -quiet -o c:\dumps -pn notepad.exe

Catch a crash dump using ADPLUS.vbs

To catch a crash dump from a running instance of NOTEPAD with process ID 1806, type:

C:\debuggers>adplus -crash -quiet -o c:\dumps –p 1806

To catch crash dumps on all instances of NOTEPAD.exe, type:

C:\debuggers>adplus -crash -quiet -o c:\dumps -pn notepad.exe

Note that after starting adplus, it will quickly exit since all it does is setting up CDB debugger for the work. After adplus command window exits, you will notice CDB command window come up(minimized by default). Just wait till the CDB finishes. The command windows will close.

Catch a crash dump on any crashing process using CDB.exe

Since adplus utility can only catch crash dumps for targeted process, it cannot be used system wide to capture crash dump for any crashing process. If we want to overcome the limitation of Dr. Watson, we can use CDB debugger for this purpose. To do this, type:

C:\debuggers> cdb -iaec "-c \".dump /u /ma c:\dumps\av.dmp;q\""

This will configure CDB debugger as the default handler for crash by AeDebug registry key. You can verify the setting by browsing to registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

And see these two values:

Value name: Auto Value data: 1

Value name: Debugger Value data: “c:\debuggers\cdb.exe” -p %ld -e %ld -g -c “.dump /ma /u c:\av.dmp;q”

Except for a different debugger, this configuration is identical to the configuration described above for using NTSD.exe. Since NTSD.exe does not have the feature to configure AeDebug registry key, we have to do it manually in the previous scenario.

The advantage of using CDB as system wide crash handler is that it can capture crash dumps for any process on Windows XP/Server 2003/Vista.

There are a lot more features to discuss about the Debugging Tools for Windows and there are a lot of resources out there.

Before we leave this topic another cool feature of both CDB and WinDBG is that you can load a dump file into them for analysis and if you want to generate a smaller dump file to share the callstacks or something basic with another person via e-mail for instance. You can generate a minidump using this command while debugging the dump:

.dump /m c:\smallerDump.dmp

This can be very helpful for providing a bit of information without having to transfer a huge DMP file.

UserDump.exe

Crash Dumps and hang dumps can be taken with the User Dump tool. For all of the details and download information check out http://support.microsoft.com/kb/241215

Dumps and Development Time

Now when you are developing there are a couple of cases where you want to look at dump generation.

Visual Studio

Where do I get it?

You purchase it.

How do I use it?

To generate dump files you need to have the C++ tools installed which will enable you to do Native Debugging. Once you enable Native Debugging then whenever you have “broken” into the debugger you can go to to the Debug menu and select Save Dump As… and that will allow you to save a dump file. This can be very helpful on a developers machine when they encounter a problem in an application they are debugging and want to save it for later analysis. Also, I have used this to capture dumps of Visual Studio when it is going weird. Just pop open a second instance of VS and attach to the first and take a memory dump.

MiniDumpWriteDump

Where do I get it?

This is an API that you would have to build into your application to enable your application to generate a dump file.

How do I use it?

This is an API to generate dumps so it cannot be used directly but would have to be coded into a tool or application. So customers will actually bake this into their Native Unhandled Exception filter. MiniDumpWriteDump can have a dump taken using the following code:

#include <dbghelp.h>
#include <shellapi.h>
#include <shlobj.h>

int GenerateDump(EXCEPTION_POINTERS* pExceptionPointers)
{
    BOOL bMiniDumpSuccessful;
    WCHAR szPath[MAX_PATH]; 
    WCHAR szFileName[MAX_PATH]; 
    WCHAR* szAppName = L"AppName";
    WCHAR* szVersion = L"v1.0";
    DWORD dwBufferSize = MAX_PATH;
    HANDLE hDumpFile;
    SYSTEMTIME stLocalTime;
    MINIDUMP_EXCEPTION_INFORMATION ExpParam;

    GetLocalTime( &stLocalTime );
    GetTempPath( dwBufferSize, szPath );
    StringCchPrintf( szFileName, MAX_PATH, L"%s%s", szPath, szAppName );
    CreateDirectory( szFileName, NULL );

    StringCchPrintf( szFileName, MAX_PATH, L"%s%s\\%s-%04d%02d%02d-%02d%02d%02d-%ld-%ld.dmp", 
               szPath, szAppName, szVersion, 
               stLocalTime.wYear, stLocalTime.wMonth, stLocalTime.wDay, 
               stLocalTime.wHour, stLocalTime.wMinute, stLocalTime.wSecond, 
               GetCurrentProcessId(), GetCurrentThreadId());

    hDumpFile = CreateFile(szFileName, GENERIC_READ|GENERIC_WRITE, 
                FILE_SHARE_WRITE|FILE_SHARE_READ, 0, CREATE_ALWAYS, 0, 0);

    ExpParam.ThreadId = GetCurrentThreadId();
    ExpParam.ExceptionPointers = pExceptionPointers;
    ExpParam.ClientPointers = TRUE;

    bMiniDumpSuccessful = MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), 
                    hDumpFile, MiniDumpWithDataSegs, &ExpParam, NULL, NULL);

    return EXCEPTION_EXECUTE_HANDLER;
}

From http://msdn2.microsoft.com/en-us/library/bb204861.aspx

Existing tools for Windows XP/Server 2003

Dr. Watson

Where do I get it?

It is found at %SystemRoot%\system32\drwtsn32.exe and is distributed with Windows XP/Server 2003 and earlier versions.

How do I use it?

Configure Dr. Watson by typing:

c:\windows\system32>drwtsn32

You can configure the location of the memory dump (the default location is C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson\user.dmp), the type of memory dump (for dump analysis purpose, select “Full” for Crash Dump Type. The default type is Mini). The problem with Dr. Watson is that it overwrites the user.dmp file. If you have more than one process crash or the same process crash due to different reasons, you have to make sure to move the user.dmp file before it is overwritten.

NTSD.exe

Where do I get it?

From %SystemRoot%\System32 folder and is a debugger distributed with Windows XP/Server 2003 and earlier versions.

How do I use it?

It’s a command line debugger and can be used to capture crash dump as well as hang dumps.

Crash Dump - To set up NTSD as system wide handler for crash, add two values under under AeDebug registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

Value name: Auto Value data: 1

Value name: Debugger Value data: “ntsd.exe” -p %ld -e %ld -g -c “.dump /ma /u c:\av.dmp;q”

Make sure to include the quotes in Value data.

Upon process crash, OS will invoke NTSD.exe which will in turn attach to the process and capture a memory dump by executing the .dump debugger command.

If you are curious what the command line means, the “-c” switch is for the debug command to be executed by NTSD debugger. The command “.dump” is for generating the memory dump. The switch “/ma” is for mini dump with all data streams. The “/u” switch is for the debugger to use a unique file name based on timestamp. The “;” delimits the first command. The second command “q” is for debugger to terminate the process and exit.

Hang Dump - NTSD is a full featured debugger. It can be used to capture a hang dump given the process ID. For example, if NOTEPAD.exe is running with process ID 1806 (process ID can be obtained from task manager), you can type this command to capture a hang dump:

C:\>ntsd -c “.dump /ma /u c:\hang.dmp;qd” -p 1806

If you don’t like to type the whole command line again and again, you can create a batch file: HangDump.bat with this command:

ntsd -c “.dump /ma /u c:\hang.dmp;qd” -p %1

To use the batch file, type:

C:\>HangDump 1806

Generating dumps with Vista

Vista does not ship with Dr. Watson or NTSD. Instead, Vista has “Problem Reports and Solutions” which is located under Control Panel->System and Maintenance.

Capture a hang dump in Vista

Inside Task Manager, select the process , right mouse click “Create Dump File”.

Capture a crash dump in Vista

For process crash, Windows Error Reporting (WER) will try to analyze the crash first and then display this message box(where BADAPP is the crashing application):

When clicking “Close program”, the process will exit. By default no crash dump file will be kept on the local system. However, if you wish to retain it, you can modify this registry value ForceQueue to 1, which is located at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting

For dump files running in system context or elevated are located at:

%ALLUSERSPROFILE%\Microsoft\Windows\WER\[ReportQueue | ReportArchive]

Dump files from other processes are located at:

%LOCALAPPDATA%\Microsoft\Windows\WER\[ReportQueue | ReportArchive]

Starting with Vista SP1 and Windows Server 2008, more features for crash dumps will be supported. For more information, see Collecting User-Mode Dumps at http://msdn2.microsoft.com/en-us/library/bb787181(VS.85).aspx

Credits

A lot of people contributed thoughts comments and work to this so I just want to provide them with credit:

Linkai Yu who did the bulk of the work. (I will introduce you to him in a subsequent post!)
Michael Wiley, Pierre Donyegro, David Wu, Greg Varveris, Sean Thompson and Aaron Barth who contributed and helped review.

ASP.NET and Unit Tests

pfedevblog — Mon, 12 Nov 2007 07:01:15 GMT

I was onsite the other day and the customer wanted to use Visual Studio 2005 to auto generate the Unit Test stubs for their ASP.NET application. They have a lot of rules tied up in the ASP.NET application project. When we tried to generate the Unit tests we kept getting the following error:

Source Code cannot be sufficiently parsed for code generation. Please try to compile your project and fix any issues.

Well, needless to say the project compiled fine (and had been for a while) and ran fine. We could not find any issues to fix. My first thought was that this was a limitation because of the way they created their ASP.NET project. So we got some details:

Originally Created in VS.NET 2003
Migrated to VS 2005
They did not convert to the new Page Model with App_Code and such.

After doing some digging I found out that the Unit Test Generation for some reason expects that the project has at least an empty "Settings." So we opened the properties on the project and clicked Settings. Sure enough there was nothing there. So we clicked the link to create the "Settings" and got the grid that would enable us to add settings. We just left it blank and rebuilt. At that point we retried the generation of the Unit Tests and everything went smoothly.

Thanks,
Zach

Welcome...

pfedevblog — Mon, 12 Nov 2007 06:53:29 GMT

Just a quick note about the team that is doing the blogging!

We are a group of engineers that do onsite support of Microsoft customers that are developing applications (internal to their company and ones that are shipped externally) that are based on Microsoft technologies. This means a lot of debugging and troubleshooting. We are actually the team that is responsible that owns the Advanced Win32 Debugging and Advanced .NET Debugging courses that are taught to Microsoft's Premier Customers.

In posts on this blog we hope to share some of those experiences with the community to hopefully make things easier for others out there. This will be a team effort so we will be introducing bloggers as they make their debut!

Since I am kicking off this post I will do my obligatory introduction. My name is Zach Kramer. I have been at Microsoft for about 6 years and on the PFE team for the past 2 years. I focus on C++, ASP.NET, Visual Studio and other developer products. I spend a lot of time debugging issues and I am an instructor both of the debug courses. I have worked with customers all over the US and even some in Europe. I will be following this up with a couple of technical posts so it is not all just fluff. ;-)

Thanks,
Zach