CoreCLR's Blog

Archive for the ‘Debugging’ Category

Debugging Release Builds

Posted by coreclr on October 30, 2009

This is a nice little trick you might not know.

Lets say you have an application build in release
mode (/debug:pdbonly /optimize+) and you want to attach the debugger directly to a running instance.

To keep it simple, this is our app:

public partial class Window1 : Window
      {
          public Window1()
          {
              InitializeComponent();
          }

          private void button1_Click(object sender, RoutedEventArgs e)
          {
              Cal(100);
          }

          int Cal(int x)
          {
              return x * x;
          }
      }

We set a break point in this line and attach to the process:

return x * x;

But the debugger will never break in our code!

The reason is that the JIT compiler has inlined the method call (remember that will compiled with /optimize+)

This is indeed a good thing. In most cases, we want the JIT compiler to have the option to inline our production code.

We can see that the module is optimized in the modules window in VS:

 image

Disable JIT Optimization

For debugging purposes, we can actually disable JIT Optimization without rebuilding the code.

Put an ini file (yes ini) in the same folder as the exe file. The filename should match the exe filename, just with ini as extension. In this case WpfApplication1.exe and WpfApplication1.ini.

The ini file should contain these 3 lines:

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

This will tell the JIT compiler not to optimized the code, so the method-call won’t be inlined.

We can now see that the loaded module is not optimized:

image

Remember to disable “Enter Just My Code” in VS.NET (Tools –> Options –> Debugger)

Advertisements

Posted in .NET, Debugging, Visual Studio, WPF | Leave a Comment »

Using DebugView during Silverlight development

Posted by coreclr on October 24, 2009

DebugView is a nice little utility that lets you monitor debug output on your local system. It can display Win32 debug output, so when you use Debug.WriteLine() it will be displayed in DebugView.

This is very handy during Silverlight development, since we cannot write to a local log file and monitor that using Grep or something else.

One specific scenario where its really useful, is when you want to get client side log information for a Silverlight application that runs on a machine without a debugger installed.

Lets look at an example:

We have an Silverlight application with a button event handler that uses Debug.WriteLine to output some information.

private void Button_Click(object sender, RoutedEventArgs e)
{
  Debug.WriteLine(DateTime.Now.ToLongTimeString());
}

If you run this on you development box, you don’t really need DebugView. You can just look at the Visual Studio’s output window.

But if you run this on at machine without a debugger, you can use DebugView to grab the output. Here is a screenshot at this in action:

DebugView

(use Ctrl+x to clear the output)

Using DebugView in Release Mode

Since Debug.WriteLine has the [Conditional("DEBUG")] attribute defined, we can only use it when the DEBUG symbol is defined. By default this symbol is not defined when we compile in Release mode.

In the full framework, we could use Trace.WriteLine(). But in Silverlight Trace is internal, so we cannot use it.

I you really want to use Debug.WriteLine in Release Model, you could explicit define the DEBUG symbol like this:

#define DEBUG
using System.Diagnostics;

namespace DebugViewTest
{
    public static class DebugUtil
    {
        public static void WriteLine(string message)
        {
            Debug.WriteLine(message);
        }
    }
}

Now we can get client side logs from a machine that runs our Silverlight application in Release mode.

In most cases I would give the user a debug version, an let him reproduce the issue. But there might be scenarios where you don’t have that option.

Another option is to use Isolated Storage as logging storage. We will look at this in a future post.

Posted in .NET, Debugging, Silverlight | 2 Comments »