David Kline : Diagnostics

.NET Compact Framework v3.5 Power Toys Released!

DavidKlineMS — Thu, 20 Dec 2007 07:05:27 GMT

I've been meaning to post this for the last week...

The .NET Compact Framework v3.5 Power Toys have officially been released. You can download the Power Toys from here.

See the .NET Compact Framework Team weblog for details on the included tools.

Enjoy!
-- DK

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

CoreCon API: Brought to you by the Visual Studio for Devices team

DavidKlineMS — Sat, 08 Dec 2007 00:42:42 GMT

The Visual Studio for Devices team has been posting a very interesting and informative series on the CoreCon API. I highly encourage anyone interested in writing remote tools to read the series. In fact, I recommend everyone interested in developing applications and/or tools for devices to subscribe to their RSS feed.

As of this posting, there are five installments to the series:
Part I
Part II
Part III
Part IV
Part V

Enjoy!
-- DK

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

Steven Pratschner on the CLR Profiler for the .NET Compact Framework

DavidKlineMS — Thu, 29 Nov 2007 03:16:59 GMT

I love tools. Debuggers, analyzers, performance monitors, profilers, everything. In version 1 of the .NET Compact Framework, the only available tools where the Visual Studio debugger and the performance counter data file (also known as the app.stats file). Version 2 added diagnostic logs and in Service Pack 1, the Remote Performance Monitor.

Version 3.5's power toys adds one of the most asked for tools - the CLR Profiler. This is a very cool tool that enables developers to drill into the allocations made by their applications: what object types, how many of them, what methods are creating them, etc. With the volume of the data the CLR Profiler provides, it can sometimes be hard to know where to begin.

To our rescue comes Steven Pratschner and his series on the CLR Profiler for the .NET Compact Framework. He's up to three installments and I highly encourage anyone interested in application performance and memory usage to read them. I'm currently devouring them and learning quite a bit.

Part 1: Getting Started
Part 2: Histograms and "Show who Allocated"
Part 3: The Timeline View

Enjoy!
-- DK

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

.NET Compact Framework v3.5 Power Toys CTP

DavidKlineMS — Thu, 13 Sep 2007 20:59:52 GMT

The .NET Compact Framework team made an exciting CTP available this week. The .NET Compact Framework v3.5 Power Toys September 2007 CTP release contains some old friends (ex: Remote Performance Monitor) and ads some great new ones (Service Model Metadata Tool, App Configuration Tool, etc).

Here's what the download page has to say about the included tools:

Remote Performance Monitor and GC Heap Viewer – Provides real time counter data (ranging from Garbage Collector activity to type loading info) on a running NETCF application. The GC Heap Viewer feature allows you to capture the managed heap at any moment your app is running to view live references, and allows you to compare multiple snapshots to find memory leak issues.

NETCF CLR Profiler – CLR Profiler is an instrumenting allocation profiler for NETCF applications. It provides detailed allocation visualizations, allocation callstacks visualizations and useful for diagnosing memory management issues.

App Configuration Tool (NetCFcfg.exe) - On-device tool for specifying what version of the NETCF runtime an application will run against, displaying installed versions of NETCF and displaying info about DLLs in the GAC.

NETCF ServiceModel Metadata Tool – The .NET Compact Framework ServiceModel Metadata Tool (netcfsvcutil.exe) allows you to generate a Windows Communication Foundation (WCF) client proxy to help developers consume WCF services on device. Like svcutil.exe, which is the desktop version of the utility, netcfsvcutil.exe is a command-line tool that generates service model code from metadata documents and generates metadata documents from service model code.

Remote Logging Configuration Tool – The Logging Configuration Tool enables users to easily configure logging options on a NETCF device including: loader, interop, network, error and finalizer logs.

NETCF Network Log Viewer – A utility for viewing NETCF network log data.

Dan Horbatt and Andrew Arnott talk in detail about the new Service Model Metadata Tool here (Dan) and here (Andrew).

I highly recommend downloading and using the power toys. And as always, please send us your feedback.

Enjoy!
-- 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.

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.

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.

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.

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.

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.