Debugging an Existing Extension

A extension that has been running properly might start failing. You should determine what is causing the failure and make the necessary changes to the extension to prevent the failure. This topic shows you how to determine if the failure is caused by the extension and how to run the extension in the Visual Studio 2005 debugger so that you can determine where the failure occurs.

Looking for the Failure

If Microsoft Identity Integration Server 2003 is not running properly, the first place you should look to find the source of the failure is in the Operations window in the Identity Manager. This view gives a summary of the management agent run profiles that have been successfully run.

To view the Operations window

• On the Identity Manager toolbar, click Operations.

In the Operations window, you can see which management agent run profile failed. If the management agent run profile that failed uses a extension, you will need to debug the extension.

Loading an Existing Extension Into the Debugger

The Visual Studio 2005 debugger allows you to step through each line of the source code to see exactly what is happening in the extension. To perform source-level debugging on a extension, it is necessary to install a debug build of the extension assembly and have the proper source code available. If the Visual Studio 2005 project files are available, you can debug the extension as shown in Attaching the Debugger to the Process. If the project files are not available, but the source files and a debug build of the extension assembly is available, you can still perform source-level debugging on the extension by performing the following steps.

1. Open Visual Studio 2005 with no project open.

2. In the Visual Studio 2005 menu, select Tools - Debug Processes.

3. In the Processes window, make the following settings:

   • Set Transport: to Default.
   • Set Name: to the Microsoft Identity Lifecycle Manager 2007, Feature Pack 1 server computer name.
   • Clear the Show system processes check box.
   • Select the Show processes in all sessions check box.

4. Select miiserver.exe in the Available Processes list and press the Attach button. The extension must be configured to run in-process. The Attach to Process dialog box is displayed.

5. In the Choose the program types that you want to debug list, select the Common Language Runtime check box and clear all other check boxes. This step is important because it affects what happens when the debugger is stopped or detached. If Native is selected, the ILM 2007 FP1 server process will have to be terminated to stop debugging.

6. Press OK in the Attach to Process dialog box.

7. In the Processes window, set When debugging is stopped: to Detach from this process.

8. Press the Close button in the Processes window. The debugger is now attached to the miiserver.exe process.

9. Open the desired extension source files in Visual Studio and add any desired breakpoints. The breakpoints will be displayed with a '?' character until the extension assembly is actually loaded. For more information on breakpoints, see Setting Breakpoints.

The extension can now be debugged normally. For more information on debugging a extension, see the following topics:

• Running an Extension
• Viewing Variables
• Attaching the Debugger
• Sending Text to the Debug Output Window

Debugging an Unhandled Exception

When a module does not handle an exception, a dialog box will be displayed to the user asking them if they want to debug the module that did not handle the exception and providing a list of the installed debuggers to use for debugging. If you choose to debug the module, the module will be loaded into the chosen debugger. This is known as "just-in-time debugging." You can use this feature to debug a extension that has not handle an exception even though the extension was not being run in the debugger at the time of the exception.

Just-in-time debugging allows you to obtain run state information at the time the exception occurred which will aid in troubleshooting the problem. It may be possible to determine the exact cause of the exception after the fact, but valuable debugging information, such as how to duplicate the exception, can be obtained.

Send comments about this topic to Microsoft

Build date: 2/16/2009