David Kline : Debugging

Quick Tip: Debugging Smart Device Unit Tests

DavidKlineMS — Mon, 12 Nov 2007 21:54:08 GMT

While browsing MSDN today, I came upon a handy article that I wanted to share. Titled 'How to: Debug while Running a Smart Device Unit Test', it provides step by step instructions on debugging your test projects.

There is one additional step I would like to add to those listed in the article.

WARNING: Using Remote Registry Editor incorrectly can cause serious problems that may require you to hard reset your device. Microsoft cannot guarantee that problems resulting from the incorrect use of Remote Registry Editor can be solved. Use Remote Registry Editor at your own risk.

7. Disable support for attaching to managed processes
To do this, use the Visual Studio Remote Registry Editor:

a. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework
b. Set the value of Managed Debugger\AttachEnabled to 0
-or-
Delete the Managed Debugger node

Take care!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
The information contained within this post is in relation to beta software. Any and all details are subject to change.

What is a Side Effect?

DavidKlineMS — Fri, 06 Oct 2006 21:54:00 GMT

We've all heard the commercials or read the prescription information sheets describing the possible side effects of medications. The side effects described are typically negative (ex: upset stomach). There are other side effects of a more positive nature; a medication helping treat an illness that it was not designed for, etc. In software, side effects are very similar. Software side effects are any 'unexpected' change in application behavior or data / object state that occur due to execution of some code.

Side effects in software are quite often encountered when debugging. Evaluating a function in the Visual Studio immediate window or changing which statement to be executed next (set next statement / set instruction pointer) can (and likely will) create side effects. A prime example of side effects while debugging is setting the next statement to either skip or re-execute a portion of code. If any of the code that is skipped or re-executed alters state (global, class or local), the behavior of the application will be altered, often unexpectedly.

Software side effects are not limited to debugging -- they can manifest anywhere application state is referenced. Debugging is often the easiest way to recognize a side effect (ex: a value unexpectedly changes in the Autos, Locals or Watch window). Be on the lookout for side effects during your debugging session, they can point the way towards otherwise hard to track down bugs.

Take care,
DK

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.

Command Line Debugging Revisited - Part 6: IL Debugging Commands

DavidKlineMS — Thu, 28 Sep 2006 00:16:00 GMT

Dan Elliott recently posted about the IL OpCodes supported by the .NET Compact Framework. This got me inspired to talk about the IL debugging commands in the .NET Compact Framework MDbg extension (mdbgnetcf.dll).

Commands
dis[assemble]
in[ext]
is[tep]
o[ut]

As with the previous installments of this series, I will be using the Visual Studio 2005 WebCrawler sample application as the debuggee. You can download the sample from here. To debug at the IL level, we first need to get connected to the debuggee (Device Emulator users should refer to this addendum).

Once connected, we can set a breakpoint on an interesting method, I will use Crawler.Crawl().

[p#:0, t#:0] mdbg> x webcrawler!*Crawl*
~0. Microsoft.Samples.NetCF.Crawler.add_CurrentPageEvent(value)
~1. Microsoft.Samples.NetCF.Crawler.remove_CurrentPageEvent(value)
~2. Microsoft.Samples.NetCF.Crawler.add_PageFoundEvent(value)
~3. Microsoft.Samples.NetCF.Crawler.remove_PageFoundEvent(value)
~4. Microsoft.Samples.NetCF.Crawler.add_CrawlFinishedEvent(value)
~5. Microsoft.Samples.NetCF.Crawler.remove_CrawlFinishedEvent(value)
~6. Microsoft.Samples.NetCF.Crawler..ctor(startingPage,noProxy)
~7. Microsoft.Samples.NetCF.Crawler.Start()
~8. Microsoft.Samples.NetCF.Crawler.Stop()
~9. Microsoft.Samples.NetCF.Crawler.PageIsHtml(pageAddress,status)
~10. Microsoft.Samples.NetCF.Crawler.GetPageData(pageUri,pageData)
~11. Microsoft.Samples.NetCF.Crawler.GetPageLinks(pageUri,pageBody,tag,attribute,links)
~12. Microsoft.Samples.NetCF.Crawler.Crawl()
~13. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler..ctor(object,method)
~14. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.Invoke(sender,e)
~15. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.BeginInvoke(sender,e,callback,object)
~16. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.EndInvoke(result)
~17. Microsoft.Samples.NetCF.MainForm.HandleCrawlFinishedEvent(sender,e)
[p#:0, t#:0] mdbg> b ~12
Breakpoint #1 bound (:1!Microsoft.Samples.NetCF.Crawler::Crawl(+0))
[p#:0, t#:0] mdbg> g

After hitting the breakpoint, we can look at the disassembly using the dis[assemble] command.

STOP: Breakpoint 1 Hit
located at line 380 in Crawler.cs
[p#:0, t#:1] mdbg> dis 5
IL at 0x49e0172c
*[IL:0000] 00: nop
 [IL:0001] 14: ldnull
 [IL:0002] 0a: stloc.0
 [IL:0003] 00: nop
 [IL:0004] 28:4100000a call System.StringComparer::get_InvariantCultureIgnoreCase

Stepping through IL code is as easy as stepping through high level languages (C#, VB.Net) using the in[ext] command.

p#:0, t#:1] mdbg> in
L at 0x49e0172c
 [IL:0000] 00: nop
*[IL:0001] 14: ldnull
 [IL:0002] 0a: stloc.0
 [IL:0003] 00: nop
 [IL:0004] 28:4100000a call System.StringComparer::get_InvariantCultureIgnoreCase

This is a pretty long method and single stepping can be time consuming. To save me some time, I am going to set an additional breakpoint on the call to Crawler.GetPageData().

[p#:0, t#:1] mdbg> sh 100
< additional lines removed for space / clarity >
425 LinkInfo li = (LinkInfo)links[page];
426 // check that the page contains html text
427 try
428 {
429 // get the currently stored HttpStatusCode
430 // for the target page
431 HttpStatusCode currentStatus = li.StatusCode;
432
433 // check to see if we have tried to connect
434 // and if the page is HTML
435 if (((HttpStatusCode)0 == currentStatus) &&
436 PageIsHtml(page, out currentStatus))
437 {
438 // read the page
439 Uri pageUri = new Uri(page);
440 string pageData = "";
441 currentStatus = GetPageData(ref pageUri,
442 out pageData);
< additional lines removed for space / clarity >
[p#:0, t#:1] mdbg> b 441
Breakpoint #2 bound (line 441 in Crawler.cs)
[p#:0, t#:1] mdbg> g

Now that I am at the second breakpoint, I would like to step into the call to Crawler.GetPageData(). As with in[ext], there is a corresponding step into command for IL: is[tep].

STOP: Breakpoint 2 Hit
441: currentStatus = GetPageData(ref pageUri,
[p#:0, t#:1] mdbg> is
IL at 0x49e01388
*[IL:0000] 00: nop
 [IL:0001] 16: ldc.i4.0
 [IL:0002] 0a: stloc.0
 [IL:0003] 14: ldnull
 [IL:0004] 0b: stloc.1

The stack shows that we are at the start of the Crawler.GetPageData method.

[p#:0, t#:1] mdbg> w
Thread [#:1]
*0. Microsoft.Samples.NetCF.Crawler.GetPageData (Crawler.cs:216)
 1. Microsoft.Samples.NetCF.Crawler.Crawl (Crawler.cs:441)

I can now step through Crawler.GetPageData in IL as desired.

[p#:0, t#:1] mdbg> in
IL at 0x49e01388
 [IL:0000] 00: nop
*[IL:0001] 16: ldc.i4.0
 [IL:0002] 0a: stloc.0
 [IL:0003] 14: ldnull
 [IL:0004] 0b: stloc.1

When I am no longer interested in debugging the method, I can return to the caller using the o[ut] command. This returns me to where I left off in the Crawler.Crawl method.

[p#:0, t#:1] mdbg> o
441: currentStatus = GetPageData(ref pageUri,

The stack and source confirm that we have returned to the Crawler.Crawl() method at the call to Crawler.GetPageData().

[p#:0, t#:1] mdbg> w
Thread [#:1]
*0. Microsoft.Samples.NetCF.Crawler.Crawl (Crawler.cs:441)
[p#:0, t#:1] mdbg> sh 5
436 PageIsHtml(page, out currentStatus))
437 {
438 // read the page
439 Uri pageUri = new Uri(page);
440 string pageData = "";
441:* currentStatus = GetPageData(ref pageUri,
442 out pageData);
443
444 // if we successfully retrieved the page data
445 if (HttpStatusCode.OK == currentStatus)

For more information on the commands I have used here, please refer to the MDbg h[elp] command.

Take care,
-- DK

Disclaimers:
This posting is provided "AS IS" with no warranties, and confers no rights.

Command Line Debugging Revisited - Part 5: The X Command

DavidKlineMS — Wed, 13 Sep 2006 22:53:00 GMT

In the previous installment, I talked about attaching to running processes using MDbg. As part of that discussion, I used the X command. Today, I'd like to spend a little time on X. The X command is one of those great features of MDbg that I think is worth the price of admission by itself.

From MDbg's online help:

mdbg> ? x
abbrev: x
Usage: x [-c numSymbols] [module[!pattern]]
    Displays functions matching [pattern] for a module. If numSymbols is
    provided, the output is limited to the given number. If !regex is not
    provided, all functions are displayed. If module is not provided either,
    all loaded modules are displayed. Symbols (~#) may be used to set
    breakpoints using the "break" command.
Example: x mscorlib!*String*
See Also:
    break

I won't be going into all of the features of X here, rather I will demonstrate the ways that I most often use the command.

I'll use the Visual Studio 2005 WebCrawler sample application to show some of the cool features of X in action. Once connected to the debuggee (via Run or Attach), we are ready to go.

When debugging using command line tools, one of the most challenging tasks is getting the fully qualified names of functions correct when setting breakpoints. Namespaces can get long (as you will see in my examples) and the casing of names must be 100% accurate. X makes this much much easier, as we will see.

Getting the list of loaded modules
In it's simplest form, X will display the modules loaded in your application.

[p#:0, t#:0] mdbg> x
Please specify module.
Loaded Modules:
:0 mscorlib.dll#0 (no symbols loaded)
:1 webcrawler.exe#0
:2 System.Windows.Forms.dll#0 (no symbols loaded)
:3 System.dll#0 (no symbols loaded)
:4 System.Drawing.dll#0 (no symbols loaded)

If you are a user of the Modules window in the Visual Studio 2005 debugger, as I am, this usage will be very familiar and handy. The one useful thing missing from this display is the path from where the symbols were loaded, which the Visual Studio 2005 Modules window provides.

Setting a breakpoint on a function
My favorite way to use X is to help me set breakpoints on functions. As I mentioned earlier, entering fully qualified names exactly right can be challenging, especially when they get long. X really helps here by allowing us to search for functions by name fragments. In the example below, I am looking for anything (methods, classes, etc) with "Crawl" as part of the name.

[p#:0, t#:0] mdbg> x webcrawler.exe!*Crawl* ~0. Microsoft.Samples.NetCF.Crawler.add_CurrentPageEvent(value) ~1. Microsoft.Samples.NetCF.Crawler.remove_CurrentPageEvent(value) ~2. Microsoft.Samples.NetCF.Crawler.add_PageFoundEvent(value) ~3. Microsoft.Samples.NetCF.Crawler.remove_PageFoundEvent(value) ~4. Microsoft.Samples.NetCF.Crawler.add_CrawlFinishedEvent(value) ~5. Microsoft.Samples.NetCF.Crawler.remove_CrawlFinishedEvent(value) ~6. Microsoft.Samples.NetCF.Crawler..ctor(startingPage,noProxy) ~7. Microsoft.Samples.NetCF.Crawler.Start() ~8. Microsoft.Samples.NetCF.Crawler.Stop() ~9. Microsoft.Samples.NetCF.Crawler.PageIsHtml(pageAddress,status) ~10. Microsoft.Samples.NetCF.Crawler.GetPageData(pageUri,pageData) ~11. Microsoft.Samples.NetCF.Crawler.GetPageLinks(pageUri,pageBody,tag,attribute,links) ~12. Microsoft.Samples.NetCF.Crawler.Crawl() ~13. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler..ctor(object,method) ~14. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.Invoke(sender,e) ~15. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.BeginInvoke(sender,e,callback,object) ~16. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.EndInvoke(result) ~17. Microsoft.Samples.NetCF.MainForm.HandleCrawlFinishedEvent(sender,e)

When we search by a part of the name, we get a numbered list of symbols that match our fragment. If the list contains our desired function, we can set a breakpoint very easily by specifying the index of the function within the list. The results above returned all methods from the Crawler class as well as the event handler for the CrawlFinishedEvent within the MainForm class. I am interested in debugging the event handler, so I'll set a breakpoint there.

[p#:0, t#:0] mdbg> b ~17 Breakpoint #1 bound (:1!Microsoft.Samples.NetCF.MainForm::HandleCrawlFinishedEvent(+0))

This is much more convenient than retyping the name (Microsoft.Samples.NetCF.MainForm.HandleCrawlFinishedEvent), or using the Mark - Copy - Paste feature of the Windows Command Prompt. It is important to be sure to use the tilde (~) when specifying the list index. Forgetting to do so will attempt to set a breakpoint by line number within the current source file as shown in the example below.

[p#:0, t#:0] mdbg> b 17 Breakpoint #2 bound (line 17 in MainForm.cs)

Enjoy!
-- DK

Disclaimer(s): This posting is provided "AS IS" with no warranties, and confers no rights.

Using the .NET Compact Framework Remote Performance Monitor to Configure Diagnostic Options

DavidKlineMS — Thu, 31 Aug 2006 23:26:00 GMT

Diagnostic, performance and debugging tools are very cool. The more tools available, the easier it tends to be to find and fix application issues. With Visual Studio 2005, several handy tools were added. I use the Remote Registry Editor and Remote File Viewer just about every day. Version 2 of the .NET Compact Framework added diagnostic logs (enabled via the device registry) to help identify application problems in places where it was very difficult, or not possible to find them with other tools.

One difficulty with using the diagnostic logs is setting the registry options. Modifying the registry can be intimidating and, if done incorrectly, a risky proposition. Readers familiar with my writings on using the diagnostic logs will recall that every time I mention the Remote Registry Editor, I include a warning to use the tool with great care.

A few months ago, Steven posted a tour of the .NET Compact Framework Remote Performance Monitor. He talked about installation, getting connected, publishing the statistics to the Windows Performance Monitor and touched upon what I am going to talk about today.

Did you know that you can use the .NET Compact Framework Remote Performance Monitor to configure diagnostic options on a device?

The other day, I was writing about using the MDbg command line debugger to attach to a .NET Compact Framework application and I needed to enable attach to process support. On my way to the Start menu to run the Remote Registry Editor, I noticed that I had the .NET Compact Framework Remote Performance Monitor running and remembered that it could configure the device registry for me. Having had the experience of incorrectly modifying this very registry flag while presenting at MEDC, I decided to save myself the embarrassment of making the same mistake again.

On the Device menu of the .NET Compact Framework Remote Performance Monitor, select Logging Options.

The first step that is required is to connect to your device. The steps to connect here are the same as those Steven describes to connect to the performance statistics. Once connected, you can configure your desired diagnostic settings.

Once connected, you can

Enable the Loader, Native Interop and Network logs
Configure log file naming options
Enable performance statistics (.stat) file creation
Enable attach to process support in the debugger

Enjoy!
-- DK

Disclaimer(s): This posting is provided "AS IS" with no warranties, and confers no rights.

Command Line Debugging Revisited - Part 4: Attaching to Processes

DavidKlineMS — Sat, 26 Aug 2006 02:58:00 GMT

Being able to attach to a running process is a very powerful debugger feature. It is especially handy when the application is in the field. With the CorDbg debugger, formal attach to process support was not available when debugging .NET Compact Framework applications. Using the .NET Compact Framework MDbg debugger extension (in version 2 service pack 1), support for attaching the debugger to running applications is now available from the command line.

Note: Before we can attach MDbg to our application (the Visual Studio 2005 WebCrawler sample), we must first enable attach to process support on the device. This step can be performed at any time prior to starting the application we wish to debug.

When debugging a .NET Compact Framework application, the first step in using MDbg is to load the .NET Compact Framework extension (mdbgnetcf.dll). Once the extension is loaded, we can then make a connection to our target device. These steps are documented in the Getting Started part of this series.

The next step is to start the application we wish to debug. The application can be started on the device by clicking on it's icon, or from MDbg by using the cp[roc] (create process) command. Since we are already in the debugger, I will use the cp[roc] command. For more information about cp[roc] and other process control commands, please see Command Line Debugging Revisited - Part 3: Process Control.

mdbg> cp "\program files\webcrawler.exe"

Our application should now be running on the device. To attach, we need to know the application's process identifier.

mdbg> pro Active processes on current machine: << additional processes removed for clarity >> (PID: 0x6de24e9a) webcrawler.exe

From the output above, we can see that the process identifier for the WebCrawler is 0x6de24e9a. We will use this value to attach to our application.

mdbg> a 0x6de24e9a

After attaching, we do not return to the mdbg> prompt. In order to begin debugging our application, we need to break into the debugger using Ctrl+C.

<Ctrl+C> STOP AsyncStop [p#:0, t#:no active thread] mdbg>

We are now debugging the WebCrawler! For fun, let's set a breakpoint in the Crawl method of the Crawler class.

Setting breakpoints using CorDbg was challenging; the exact name (case-sensitive) had to be entered to be able to successfully set breakpoints on methods. With MDbg this has gotten much easier. Using the x command, we can search for methods of interest within the WebCrawler module.

[p#:0, t#:no active thread] mdbg> x WebCrawler ~0. Microsoft.Samples.NetCF.Crawler.add_CurrentPageEvent(value) ~1. Microsoft.Samples.NetCF.Crawler.remove_CurrentPageEvent(value) ~2. Microsoft.Samples.NetCF.Crawler.add_PageFoundEvent(value) ~3. Microsoft.Samples.NetCF.Crawler.remove_PageFoundEvent(value) ~4. Microsoft.Samples.NetCF.Crawler.add_CrawlFinishedEvent(value) ~5. Microsoft.Samples.NetCF.Crawler.remove_CrawlFinishedEvent(value) ~6. Microsoft.Samples.NetCF.Crawler..ctor(startingPage,noProxy) ~7. Microsoft.Samples.NetCF.Crawler.Start() ~8. Microsoft.Samples.NetCF.Crawler.Stop() ~9. Microsoft.Samples.NetCF.Crawler.PageIsHtml(pageAddress,status) ~10. Microsoft.Samples.NetCF.Crawler.GetPageData(pageUri,pageData) ~11. Microsoft.Samples.NetCF.Crawler.GetPageLinks(pageUri,pageBody,tag,attribute,links) ~12. Microsoft.Samples.NetCF.Crawler.Crawl() ~13. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler..ctor(object,method) ~14. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.Invoke(sender,e) ~15. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.BeginInvoke(sender,e,callback,object) ~16. Microsoft.Samples.NetCF.Crawler.CurrentPageEventHandler.EndInvoke(result) ~17. Microsoft.Samples.NetCF.CurrentPageEventArgs.get_PageAddress() ~18. Microsoft.Samples.NetCF.CurrentPageEventArgs..ctor(page) ~19. Microsoft.Samples.NetCF.LinkInfo.get_LinkPath() ~20. Microsoft.Samples.NetCF.LinkInfo.get_StatusCode() ~21. Microsoft.Samples.NetCF.LinkInfo.set_StatusCode(value) ~22. Microsoft.Samples.NetCF.LinkInfo..ctor(path,status) ~23. Microsoft.Samples.NetCF.MainForm..ctor() ~24. Microsoft.Samples.NetCF.MainForm.Dispose(disposing) ~25. Microsoft.Samples.NetCF.MainForm.InitializeComponent() ~26. Microsoft.Samples.NetCF.MainForm.Main() ~27. Microsoft.Samples.NetCF.MainForm.startButton_Click(sender,e) ~28. Microsoft.Samples.NetCF.MainForm.HandleCurrentPageEvent(sender,e) ~29. Microsoft.Samples.NetCF.MainForm.HandlePageFoundEvent(sender,e) ~30. Microsoft.Samples.NetCF.MainForm.HandleCrawlFinishedEvent(sender,e) ~31. Microsoft.Samples.NetCF.MainForm.HandleActivityLightsEvent(unused,notused) ~32. Microsoft.Samples.NetCF.MainForm.CustomInvokeRequired()

From this list, we see that entry 12 is our desired method. To set a breakpoint on the Crawl method, we can reference the entry number.

[p#:0, t#:no active thread] mdbg> b ~12 Breakpoint #1 bound (:1!Microsoft.Samples.NetCF.Crawler::Crawl(+0))

When we continue the application (and click Start in the WebCrawler application), we stop at the beginning of the Crawl method.

[p#:0, t#:no active thread] mdbg> g STOP: Breakpoint 1 Hit located at line 380 in Crawler.cs [p#:0, t#:no active thread] mdbg>
Enjoy!
-- DK

Disclaimer(s): This posting is provided "AS IS" with no warranties, and confers no rights.

The Error Log: A New Diagnostic in .NET Compact Framework v2 Service Pack 1

DavidKlineMS — Thu, 17 Aug 2006 22:36:00 GMT

The recent release of Service Pack 1 for the .NET Compact Framework version 2 has added some very useful diagnostic tools. You may have already read about the .NET Compact Framework Remote Performance Monitor, and have hopefully used it to analyze the performance characteristics of your applications. Today, I would like to talk about another new diagnostic tool: the error log.

With the addition of support for headless devices, it became apparent that we needed a means for capturing details about unexpected errors. It is not always feasible to run applications under a debugger, and not all error conditions occur with the consistency that makes them easy to diagnose. To help address this, the error log was created. While the error log is typically most useful for headless devices, it is available for all devices running .NET Compact Framework version 2 service pack 1.

Enabling Error Logging
The Error Log is enabled via the device's registry. In my steps, below, I will be using the Remote Registry Editor that is included with Visual Studio 2005.

Start the Remote Registry Editor
- Open the Start Menu
- Select All Programs
- Select Microsoft Visual Studio 2005
- Select Visual Studio Remote Tools
- Select Remote Registry Editor
Connect to your device
- On the Target menu, select Connect
- Select your device and click OK
Enable diagnostic logging
- In the left hand pane, expand the device
- Expand HKEY_LOCAL_MACHINE
- Expand SOFTWARE
- Expand Microsoft
- Expand .NETCompactFramework
- Expand Diagnostics
  If this key does not exist, you will need to create it
  - Right click on .NETCompactFramework
  - Select New > Key Type "Diagnostics" (without quotes)
  - Click OK
- Expand Logging
  If this key does not exist, you will need to create it
  - Right click on Diagnostics
  - Select New > Key
  - Type "Logging" (without quotes)
  - Click OK
- Set the value of Enabled to 1
  If this value does not exist, you will need to create it
  - Right click on Logging
  - Select New > DWORD Value
  - Set the Name to "Enabled" (without quotes)
  - Set the value to 1
  - Click OK
Enable error logging
- In the Logging key (from step 3) expand Error
  If this key does not exist, you will need to create it
  - Right click on Logging
  - Select New > Key
  - Type "Error" (without quotes)
  - Click OK
- Set the value of Enabled to 1
  If this value does not exist, you will need to create it
  - Right click on Error
  - Select New > DWORD Value
  - Set the Name to "Enabled" (without quotes)
  - Set the value to 1
  - Click OK

To disable the Error Log, follow the above steps and set the value of Enabled to 0. To disable all logging, follow only steps 1-3, and set the value of Enabled to 0.

TIP: Set the value of UseApp (under Logging) to 1 to enable application specific log files.

Using the Error Log
To demonstrate the error log, I created a very simple application that encounters an unhandled exception. After the application exits (is terminated by clicking the Quit button), the error log file will be created.

NOTE: On headless devices, error dialogs are dismissed automatically using the default button.

After opening the log file, we can see the unhandled exception.

Caption: UnhandledException.exe Title : Error Text : An unexpected error has occurred in UnhandledException.exe. Select Quit and then restart this program, or select Details for more information. Cannot perform requested task at this time Details: (null)

On devices with display capabilities, clicking the Details button will result in the following additional data being present in the error log file.

Caption: UnhandledException.exe Title : Error Text : UnhandledException.exe ApplicationException Cannot perform requested task at this time at UnhandledException.Program.PerformTask() at UnhandledException.Program.Main() Details: (null)

As we can see, the new error log feature allows unexpected errors can now be captured in the field, without requiring users to copy large amounts of data manually from the device.

Enjoy!
-- DK

Disclaimer(s): This posting is provided "AS IS" with no warranties, and confers no rights.

Command Line Debugging Revisited - Part 3: Process Control

DavidKlineMS — Sat, 12 Aug 2006 01:19:00 GMT

In the previous parts of this series, I talked about getting started with MDbg and using the Device Emulator. Today, I would like to talk about how to use MDbg to control processes on the device being debugged.

Commands
cp[roc]
kp[roc]
pro[cessenum]

The cp[roc] command - Running a process without attaching the debugger
In my getting started post, I talked about how to connect to the NetCFLaunch application and start an application for debugging. While I typically want to debug the process that I launch, there are instances where I wish to start a process without debugging. To do so, I use the cp[roc] command as shown in the example below.

mdbg> cp "\program files\webcrawler.exe"

If the command is able to start the process, the mdbg> prompt will be displayed. If it is unable to start the process (ex: the application could not be found) an error message will be displayed.

The pro[cessenum] command - Listing the processes running on the device
It is often interesting to know exactly what processes are running on your device. Perhaps your application relies upon another process for some data or to perform a particular task. Using the pro[cessenum] command allows you to verify whether or not the partner process is running. The example, below, shows the processes running on my Windows Mobile 5.0 Pocket PC device.

mdbg> pro
Active processes on current machine:
(PID: 0x0dcb4002) NK.EXE
(PID: 0xedca5752) filesys.exe
(PID: 0x8dadc526) device.exe
(PID: 0xcd7f62ea) shell32.exe
(PID: 0xcd97c7a6) gwes.exe
(PID: 0xcd7f6732) services.exe
(PID: 0x2d4b6da6) CommLoader.exe
(PID: 0xcd517ac2) BatteryIndicator.exe
(PID: 0x2d5219ea) connmgr.exe
(PID: 0xad517b8a) srvtrust.exe
(PID: 0xed810392) repllog.exe
(PID: 0x2d4b6c76) poutlook.exe
(PID: 0xed3affce) cprog.exe
(PID: 0x2d99977a) rapiclnt
(PID: 0xeced62b2) webcrawler.exe
(PID: 0x2d0ed5be) tmail.exe
(PID: 0x8d30f68a) netcflaunch.exe

In looking at the process list, we can see that my earlier call to the cp[roc] command successfully loaded webcrawler.exe.

The kp[roc] command - Terminating a running process
There are a number of situations where being able to terminate a running process can be desirable. I find this most useful when I wish to explore failure code paths when my applications leverage another process. The following example shows using the kp[roc] command to terminate the webcrawler.exe process that I started with the cp[roc] command..

mdbg> kp 0xeced62b2

The value passed to the kp[roc] command is the process identifier (PID) listed by the pro[cessenum] command.

(PID: 0xeced62b2) webcrawler.exe

Note: Please take care when terminating a process on your device. Forcibly exiting the wrong application can lead to instability or an unresponsive device.

Tip: Use QuickEdit Mode or the Mark and Paste features of the Command Prompt to enable cut and paste within MDbg.

Enjoy!
-- DK

[Edit: fix formatting]

Disclaimer(s): This posting is provided "AS IS" with no warranties, and confers no rights.

Command Line Debugging Revisited - Part 2: The Device Emulator

DavidKlineMS — Fri, 14 Jul 2006 23:09:00 GMT

The Visual Studio 2005 Device Emulator is a very cool tool for developing, testing and debugging Windows Mobile applications. You can design for and run on the wide variety of Windows Mobile devices. In addition, you can install and use the localized images, to run your applications on international versions of the Windows Mobile operating system.

By default, the Device Emulator uses DMA as it's transport for device to desktop communications. The MDbg command line debugger supports TCP/IP for device to desktop communications. To allow MDbg to be used with the Device Emulator, there are some additional steps that are required before a connection can be established.

Abhi Khune has an excellent post on establishing a connection to the Internet using the Device Emulator. In that post, there is a paragraph talking about the DMA and TCP/IP transports where it is noted that changing the Device Emulator transport from DMA to TCP/IP is not recommended. I fully agree with the recommendation with one notable exception: it is the only means to connect MDbg to the device emulator using the .NET Compact Framework version 2 service pack 1 debugger extension (mdbgnetcf).

Note: After changing the Device Emulator's transport, you will need to reset the device.

Recommendation: I highly recommend switching the Device Emulator transport back to DMA once you are finished debugging with MDbg.

Once the Device Emulator is configured for the TCP/IP transport, there are two options for connectivity.

ActiveSync
For me, the easiest way to establish a TCP/IP connection using the Device Emulator is to use Visual Studio 2005's Device Emulator Manager and ActiveSync to "cradle" the device.

Abhi's post provides a walk-through on using the Device Emulator Manager, with many screen shots.
Virtual Machine Network Driver
Another alternative is installing the Virtual Machine Network Driver. You can download and read installation instructions in the Microsoft Download Center.

When using the Virtual Machine Network Driver, there is no need to cradle the Device Emulator using ActiveSync and the Device Emulator Manager.

Please note you will need to perform Abhi's steps once per Device Emulator image (ex: Windows Mobile 5.0 Pocket PC) you wish to use with MDbg.

With the above steps completed, you can connect and debug with MDbg as described in part 1.

Enjoy!
-- DK

[Edit: fix spelling error]

Disclaimer(s): This posting is provided "AS IS" with no warranties, and confers no rights.

Command Line Debugging Revisited - Part 1: Getting started with MDbg and .NET Compact Framework Version 2 Service Pack 1

DavidKlineMS — Fri, 14 Jul 2006 01:44:00 GMT

It's been a while since I last wrote about using the command line debugger (cordbg) with the .NET Compact Framework. Quite a bit has changed in the world of .NET Compact Framework command line debugging since that time.

With the release, last year, of version 2 of the .NET Framework SDK, a new command line debugger (MDbg) became available. MDbg is written in managed code and supports adding functionality via extension assemblies (DLLs). At the time we released version 2, the extension which adds .NET Compact Framework support was not ready. With the release of .NET Compact Framework version 2 service pack 1, our extension assembly (mdbgnetcf.dll) is now available.

If you followed my original command line debugger series, you may recall that there were several steps to getting a command line debugging session established with a .NET Compact Framework application in version 1. I'm happy to say that we have made the process of getting started quite a bit easier with our MDbg extension. I'm going to spend today's post talking about the device and run commands that are added by the mdbgnetcf extension.

Preliminary steps
Before we can get started using MDbg to debug a .NET Compact Framework application, there are a few preliminary tasks we must perform.

Download and install .NET Compact Framework version 2 service pack 1
Update your device to the service pack 1 release
Copy the following files to the \Windows folder on the device
- from <drive>:\Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target\wce400\<cpu>
  - edbgtl.dll
  - tcpconnectiona.dll
- from the service pack 1 installation folder (typically <drive>:\Program Files\Microsoft.NET\SDK\CompactFramework\v2.0\WindowsCE\<version>\<cpu>
  - netcfrtl.dll
  - netcflaunch.exe
Deploy your application file(s) to the device.

Steps 2 & 3 typically need to be performed only once per device. Step 1 once per development / debugging PC. Step 4 needs to be performed whenever the application file(s) have changed.

Getting started
Once the preliminary tasks have been performed, we can get started debugging our application using MDbg.

Run mdbg.exe
I recommend running MDbg from either a Visual Studio 2005 Command Prompt (Start Menu\All Programs\Microsoft Visual Studio 2005\Visual Studio Tools) or a SDK Command Prompt (Start Menu\All Programs\Microsoft .NET Framework SDK v2.0). This will ensure that MDbg.exe is on the search path.

I also recommend running MDbg from within the folder containing both your target executable and the symbol (.pdb) file. This allows MDbg to match the symbols to the exe and display the correct source code without any additional steps.
Load the mdbgnetcf extension

mdbg>load <path>\mdbgnetcf

It is important to note that the file extension (.dll) is left off when using the load command.

When the extension is loaded, the following message will be displayed.

.NET Compact Framework extension loaded successfully.
On your device, run NetCFLaunch.exe

When NetCFLaunch starts, it will display the transport parameters (ex: 169.254.2.1 6510) required to connect to the device. We will use the transport parameters in the next step.
Connect to the device using the device command

device 169.254.2.1 6510

When the device command successfully completes, we will have a connection to the NetCFLaunch application. The NetCFLaunch window will display "Connection SUCCEEDED".
Run your application using the run command

I will use the WebCrawler sample from Visual Studio 2005.

run "\program files\webcrawler.exe"

When the run command completes, MDbg will display the current source location (the application entry point).

STOP: Breakpoint Hit 288: { [p#:0, t#:0] mdbg>

Note: The breakpoint to which MDbg refers is the initial, temporary breakpoint managed by the debugger. This breakpoint is inserted and cleared when MDbg connects to the application.

You can now debug your application using the other MDbg commands. For a list of available commands, use the h[elp] or ? commands.

In the coming weeks, I plan on continuing this series and talking about the other commands added by the mdbgnetcf extension and show some examples of how they can be used.

Enjoy!
-- DK

Disclaimer(s): This posting is provided "AS IS" with no warranties, and confers no rights.

MEDC 2006 Update: What went wrong in the debugging demo during APP326?

DavidKlineMS — Fri, 16 Jun 2006 23:17:00 GMT

Ever since I finished my MEDC 2006 presentation (APP326 - Essential Tips and Tricks for .NET Compact Framework Application Developers), I have been bothered by the fact that one of my demos did not work 100% as I had designed and practiced. During the demo of debugging a P/Invoke call (based on this post), I was unable to re-attach to the managed application. This demo worked correctly at MEDC 2005, so why didn't it work this year?

After thinking about this for awhile, I realized that there was one major difference between 2005 and 2006... This year, I decided to show setting the AttachEnabled registry key as part of the presentation. Last year, I had pre-configured the device to support attach to process. This is was the cause of my problem.

While practicing my session, I had used the demo system (my laptop) to walk through each and every demo until I knew them backwards, forwards and inside-out. I was very careful to always leave the device and emulator images in a known state (the beta of .NET Compact Framework v2 sp1 installed, the shared folder configured, etc) so that I would not run into any problems or deployment related delays. My practices went flawlessly and the time came to do them "for real".

Those who attended the session may recall that there were actually two things that did not go smoothly for this particular demo. First, while I was careful to leave the device and emulators in a known state, I forgot to make sure that I had reset the source code before starting the debugging demo and left the Debug.Assert statements that the demo required commented and, therefore, they did not execute.

The second (actually it was the first mistake that I made) was misspelling "AttachEnabled" when editing the device's registry. Ryan Chapman later pointed out that he remembered seeing me type "AttachEnable" (missing the d). After he mentioned that, all I could think was "oh no, how could I have made that mistake". I will confirm this once I receive and watch the session recording, but I think Ryan is correct. Fortunately, the slides have the correct registry data listed.

To make a long story short, when you watch the session recording, please be aware of this error and use the registry key (AttachEnabled) that is shown in my slides and here. Sorry for the confusion that this may have caused at the show.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.
Some of the information contained within this post may be in relation to beta software. Any and all details are subject to change.

The Importance of Debugger Symbols: or Reloading Symbols while Debugging

DavidKlineMS — Thu, 16 Mar 2006 02:01:00 GMT

Have you ever attached to a managed application and been greeted with the following message ...

No symbols are loaded for any call stack frame. The source code cannot be displayed.

... and found that breakpoints could not be set, or that single step attempts cause the application to run to completion)?

While preparing one of the demos for my MEDC 2006 presentation, I found myself in this state and was reminded of the importance of making sure the correct debugger symbols can be found by the Visual Studio 2005 debugger.

Often when attaching a debugger to a running application, you are not using the system on which the application was originally compiled, or the source code may have been moved since the application was built. In these cases, the Visual Studio 2005 debugger is unable to resolve the location of the debugging symbols automatically. To be able to successfully debug your application, you will need to instruct Visual Studio 2005 as to where to find the application's symbols (.pdb file) and to attempt to reload them.

To load symbols after you have attached to an application:

On the Debug menu, select Windows and then Modules
This will open the Modules window and show the binaries loaded as part of your application, including the .NET Compact Framework runtime.
Right click anywhere within the Modules window and select Symbol Settings
In the Options dialog, click on the folder icon (to the upper right)
Type the location to the application's .pdb file (ex: c:\projects\TestApplication\bin\debug) and click OK
If you have the Load symbols using the updated settings when this dialog is closed option selected (it is selected by default), the Visual Studio debugger will attempt to reload the symbols for all loaded modules.

With the correct symbols loaded, you will be able to set breakpoints and step through your code as if you had built and deployed the application from the current system.

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Using the Interop Log to Diagnose P/Invoke Call Issues

DavidKlineMS — Sat, 04 Feb 2006 01:33:00 GMT

Sometimes, determining why an unmanaged function call (P/Invoke) has failed can be challenging. Fortunately, version 2 of the .NET Compact Framework has a new diagnostic log for this data -- the Interop Log. In June 2005, Steven Pratschner wrote a great post detailing the Inteop Log and it's contents: Diagnosing Marshalling Errors using Interop Logging.

I would like to take some time to explore a specific example where the Interop Log can save time and make P/Invoke call debugging quick and easy.

Enabling the Interop Log
The Interop Log is enabled via the device's registry. In my steps, below, I will be using the Remote Registry Editor that is included with Visual Studio 2005.

Start the Remote Registry Editor
- Open the Start Menu
- Select All Programs
- Select Microsoft Visual Studio 2005
- Select Visual Studio Remote Tools
- Select Remote Registry Editor
Connect to your device
- On the Target menu, select Connect
- Select your device and click OK
Enable diagnostic logging
- In the left hand pane, expand the device
- Expand HKEY_LOCAL_MACHINE
- Expand SOFTWARE
- Expand Microsoft
- Expand .NETCompactFramework
- Expand Diagnostics
  If this key does not exist, you will need to create it
  - Right click on .NETCompactFramework
  - Select New > Key
  - Type "Diagnostics" (without quotes)
  - Click OK
- Expand Logging
  If this key does not exist, you will need to create it
  - Right click on Diagnostics
  - Select New > Key
  - Type "Logging" (without quotes)
  - Click OK
- Set the value of Enabled to 1
  If this value does not exist, you will need to create it
  - Right click on Logging
  - Select New > DWORD Value
  - Set the Name to "Enabled" (without quotes)
  - Set the value to 1
  - Click OK
Enable interop logging
- In the Logging key (from step 3) expand Interop
  If this key does not exist, you will need to create it
  - Right click on Logging
  - Select New > Key
  - Type "Interop" (without quotes)
  - Click OK
- Set the value of Enabled to 1
  If this value does not exist, you will need to create it
  - Right click on Interop
  - Select New > DWORD Value
  - Set the Name to "Enabled" (without quotes)
  - Set the value to 1
  - Click OK

To disable the Interop Log, follow the above steps and set the value of Enabled to 0.
To disable all logging, follow only steps 1-3, and set the value of Enabled to 0.

There are a few optional settings that can be set to configure how the Interop Log is created. For details, please refer to Steven's post.

One optional setting I highly recommend is to create application specific log files. This causes the .NET Compact Framework to name the log file based on your application name. For example, if I enable logging with the UseApp option, the log file created for an application called DkTest.exe will be netcf_DkTest_interop.log.

To enable application specific log files please make the following addition to the above steps.

Enable application specific log files

In the Logging key set the value of UseApp to 1
If this value does not exist, you will need to create it

Right click on Logging
Select New > DWORD Value
Set the Name to "UseApp" (without quotes)
Set the value to 1

Click OK

Diagnosing a P/Invoke call issue
One of the things that I sometimes forget is that .NET types are not necessarily the same as Win32 types. One type, in particular, where this is true is long. On Win32, a long (or LONG) takes up 4 bytes (32 bits). In the .NET world, a long is 8 bytes (64 bits) in size.

Let's look at an example where this type size difference can cause application issues.

First, a simple function written in C/C++
int SampleFunction(long lData) { // int == long on Win32 systems return lData; }To be able to call this function, our managed application must define the signature for the P/Invoke.
[DllImport("InteropLogExampleNative.dll", SetLastError=true)] public static extern int SampleFunction(long lData);
Now we can call our function.
int result = SampleFunction(long.MaxValue);
If you add the above code to a simple project and attempt to call the P/Invoke method, depending on the data passed to the function, you may encounter "calculation errors" related to the wrong data type being sent to the unmanaged function.

If the Interop logging is enabled, we can see that the application tried to call the method with an 8 byte value when the method was expecting only 4 bytes.

[pinvokeimpl][preservesig] int InteropLogPInvokeExample.Program::SampleFunction(long ); int (I4_VAL) SampleFunction(INT64 (I8_VAL) );
To quote Steven: "The Compact Framework does not have intrinsic knowledge of the native function you are calling – it simply takes the managed definition you’ve provided and creates an equivalent native signature. If this signature doesn’t match the actual signature of the targeted native function, a marshaling error will occur."

By changing the P/Invoke signature to specify a 4 byte integer, the call succeeds.

// managed code // p/invoke method signature. // // note: a Win32 long is the same size as a .NET int [DllImport("InteropLogExampleNative.dll", SetLastError=true)] public static extern int SampleFunction(int lData);

These types of issues can sometimes be difficult to notice. For example, in our simple unmanaged (native) function, we are simply returning the value passed as the argument. If the value happens to be one that can fit within a 32 bit integer, the failure may go unnoticed. If the value exceeds that which will fit in a 32 bit integer and the code does not validate the data returned from the call, the failure may also go unnoticed.

The moral of this story is that it is very important to validate the behavior of all P/Invoke calls by examining the returned data or any other means appropriate. I also highly recommend enabling Interop logging and examining the P/Invoke signature data in the log file as a standard part pre-checkin unit testing and release criteria if your application makes calls to unmanaged functions.

Take care,
-- DK

Edit: Fix error in registry steps.
Edit: Fix UseApp steps

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Diagnosing MissingMethodExceptions and TypeLoadExceptions using the Loader Log

DavidKlineMS — Tue, 31 Jan 2006 21:59:00 GMT

Have you ever encountered a MissingMethodException or TypeLoadException when starting a .NET Compact Framework application? If you are running version 2 of the .NET Compact Framework, the Loader Log can help identify the source of the exception.

For detailed information regarding the Loader Log, please read Steven Pratschner's excellent Better Diagnostics in Whidbey: Loader Logging post.

Enabling the Loader Log
The Loader Log is enabled via the device's registry. In my steps, below, I will be using the Remote Registry Editor that is included with Visual Studio 2005.

Start the Remote Registry Editor
- Open the Start Menu
- Select All Programs
- Select Microsoft Visual Studio 2005
- Select Visual Studio Remote Tools
- Select Remote Registry Editor
Connect to your device
- On the Target menu, select Connect
- Select your device and click OK
Enable diagnostic logging
- In the left hand pane, expand the device
- Expand HKEY_LOCAL_MACHINE
- Expand SOFTWARE
- Expand Microsoft
- Expand .NETCompactFramework
- Expand Diagnostics
  If this key does not exist, you will need to create it
  - Right click on .NETCompactFramework
  - Select New > Key
  - Type "Diagnostics" (without quotes)
  - Click OK
- Expand Logging
  If this key does not exist, you will need to create it
  - Right click on Diagnostics
  - Select New > Key
  - Type "Logging" (without quotes)
  - Click OK
- Set the value of Enabled to 1
  If this value does not exist, you will need to create it
  - Right click on Logging
  - Select New > DWORD Value
  - Set the Name to "Enabled" (without quotes)
  - Set the value to 1
  - Click OK
Enable loader logging
- In the Logging key (from step 3) expand Loader
  If this key does not exist, you will need to create it
  - Right click on Logging
  - Select New > Key
  - Type "Loader" (without quotes)
  - Click OK
- Set the value of Enabled to 1
  If this value does not exist, you will need to create it
  - Right click on Loader
  - Select New > DWORD Value
  - Set the Name to "Enabled" (without quotes)
  - Set the value to 1
  - Click OK

To disable the Loader Log, follow the above steps and set the value of Enabled to 0.
To disable all logging, follow only steps 1-3, and set the value of Enabled to 0.

There are a few optional settings that can be set to configure how the Loader Log is created. For details, please refer to Steven's post.

One optional setting I highly recommend is to create application specific log files. This causes the .NET Compact Framework to name the log file based on your application name. For example, if I enable logging with the UseApp option, the log file created for an application called DkTest.exe will be netcf_DkTest_loader.log.

To enable application specific log files please make the following addition to the above steps.

Enable application specific log files
- In the Logging key et the value of UseApp to 1
  If this value does not exist, you will need to create it
  - Right click on Logging
  - Select New > DWORD Value
  - Set the Name to "UseApp" (without quotes)
  - Set the value to 1
  - Click OK

Diagnosing the exception
To illustrate how the Loader Log can help identify the cause of these exceptions, I created a custom control that was built to incorrectly reference the full .NET Framework version of the System.Windows.Forms assembly. I then built a simple application that used this control. After running the application, the Loader Log contained the following data.

MissingType. Class [myControl.CustomButton], Assembly [myControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null].
Scrolling back up the log file, we find this entry.

Failed to load [System.Windows.Forms, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=B77A5C561934E089]
In examining this entry, we see that the myControl.CustomButton assembly failed to load the System.Windows.Forms assembly. The reason was that the strong name of the System.Windows.Forms assembly (Name, Version, Culture, PublicKeyToken) was not present on my device. Take note of the value of PublicKeyToken. By comparing the PublicKeyToken value of successfully loaded assemblies (ex: System.Xml), we find that, in this instance, they do not match.

The PublicKeyToken specified in the strong name for the System.Windows.Forms assembly is that of the full .NET Framework.

To date (versions 1 and 2), the .NET Compact Framework uses the 969DB8053D3322AC as it's PublicKeyToken in system assembly strong names.

Enjoy!
-- DK

Edit: Fix UseApp steps

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

What is a Race Condition?

DavidKlineMS — Mon, 24 Oct 2005 22:39:00 GMT

I've been posting a bit, lately, on debugging multi-threaded applications. When talking about deadlocks, I mentioned that I was adding a Sleep statement to ensure that I hit the deadlock issue. The reason that I needed to force the deadlock was that, depending on timing, the code could either work, or hang the application. The example I was using was a classic "race condition". If Thread 2 completed before Thread 1 started, there would appear to be no bug. However, if Thread 1 entered the lock statement first, the application would hang.

What is a race condition?
I mentioned earlier that the situation in my example was called a "race condition". What exactly does that mean? Multi-threaded applications are very similar to sporting events such as sprints, marathons and stock car races. As with these more traditional races, for any given event, any entrant can win. In a marathon, if an unexpected entrant wins, it's exciting. In software, if an unexpected thread wins the race the results are typically unpleasant (application hangs, data corruption, etc) for users.

It has been my experience that running multi-threaded applications on multiple processor machines tends to encounter race conditions more frequently. On these systems multiple simultaneous application threads are not only possible, they are likely and in such an environment, race condition bugs have been, for me, much more likely to surface.

Debugging race conditions
How do you debug a race condition? This is a difficult question to answer. Whenever you make any change to the system such as: running on a different system, instrumenting the binary with diagnostic logging or running under the debugger, the timing characteristics of your application can be changed. This change in the application's timing can cause a different thread to win the race. If we are lucky, this causes the bug to surface. If we are not, this timing change can mask the problem.

What has worked for me has been to instrument my code (in debug builds) and run the debug build of my application (or component) under the debugger at all times while writing the code. Whenever possible, I also recommend running on a debug build of the target platform. Using the debugger to step through your code and setting breakpoints on the methods where thread safety is a requirement, you may be able to find the issue during development.

I have also found that reviewing my threading code with another developer to be a very useful strategy to find race conditions. By walking through the code and explaining how it works, I have found that many issues, not just those related to threading, can be resolved before the code gets run.

Avoiding race conditions
By far, the best approach to handling race conditions is to code proactively. If your library code could possibly be used in a multi-threaded application, use synchronization objects (locks, mutexes, ManualResetEvents, etc) to make the code thread safe. Be sure to take care and perform only thread safety critical operations within these synchronization events to avoid deadlocks such as the example shown in my earlier post (where I used a ManualResetEvent within a lock statement).

Take care,
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.