Debugging your extension code from Visual Studio

Extension code cannot run standalone, but only within ILM. To debug the code you must first attach Visual Studio to the miiserver process.

Can’t see the miiserver process?

You may have to tick options to show all processes.

ILM/MIIS installed on another machine?

You can attach to processes on remote servers, however you need to install the remote debug components on the ILM server (check your VS help for details).

It is also important to ensure that the version of the dlls on the remote server matches exactly the code you are looking at in Visual Studio.

Insert Breakpoints

Once you’ve successfully attached to the process you can insert breakpoints in your code, and then start a task in Identity Manager.

For total VS newbies, the following are useful:

  • F10 key to step through the code,
  • F5 to continue running the code until the next breakpoint,
  • Quick Watch to check the value of a variable or statement,
  • Add Watch to list variables you want to keep an eye on.

Breakpoints not hit

There are a number of reasons why a breakpoint may not be hit during a debug session. Here are some suggestions:

For VS2005, symbols not loaded

See Brad’s answer here.

Code not compiled with Debug option

Check you have compiled a “Debug” rather than a “Release” version of the dll.

Breakpoint in a code segment that is skipped

A rather obvious one this – if your breakpoint is in a subroutine, or inside something like an If or Select statement, also add a breakpoint that will be hit before the code branch, so you can find out why the segment isn’t being entered.

Breakpoint in the Initialize or Terminate subs

These subs are rather particular:

  • ILM loads the Initialize sub once at the beginning of the first call to the dll;
  • It keeps the Initialize sub in memory for 5 minutes after all calls the the dll finish;
  • After the 5 minutes, ILM runs the Terminate sub, and unloads the Initialize sub.

So if your breakpoint is in the Terminate sub you will have to wait 5 minutes for it to be hit!

And if it’s in the Initialize sub, and you’re running the dll over and over again (within 5 minutes) ILM will not run it again!

You can force ILM to reload the Initialize sub by modifying and rebuilding the dll, or by restarting the MIIS service.

MA running in a seperate process

In the MA configuration, if you ticked “Run this rules extension in a seperate process”, you will not be able to debug it via the miiserver process. You would have to, somehow, attach to the seperate process while it is active. It is much simpler to just make sure this option is unticked whenever you need to debug.

Be especially aware when creating CDS extensions for Extensible MAs – they have this option ticked by default.

Provisioning (or individual dlls) turned off

Check that provisioning is enabled in Identity Manager under Tools -> Options. Also check if this installation has XML files which switch on or off individual dlls.

Error happens before the extension code starts to run

Some errors (typically involving connection to the data source) happen even before the code gets a chance to run. You should see a stopped-extension-dll-exception, and there will be more information in the Windows Application Event log.


Make use of the Preview function in ILM/MIIS to simulate a synchronization of a selected connector space object. In ILM you can now commit this preview, but for code debugging it is usually more useful to replay the sync as many times as you need to get the code right.

In summary

You can learn a lot about how ILM works by watching your code running in debug mode. It’s an essential tool for building a stable ILM environment so have fun using it!

5 Replies to “Debugging your extension code from Visual Studio”

  1. Hello. I have a XML file which contains some scandinavic characters.
    MIIS does not read those files. Without scandinavic characters works fine.
    I’m using the OCG.Utility.XML.. How to make this working with scandis too?

  2. That’s really a .net question. You could try modifying the OCG add-in if you have the source code for it – otherwise you’ll have to write your own XML parsing utility. It’s not too difficult with System.Xml.

  3. I’d wish you could post full source, as I’m kinda thrown off by partial code (in the prev. article too)!
    I find it hard to find any decent explanation of how to truly, for example, make an MA extension. A lot of “you should do this, and that”, but “this and that” only casts light on some of the extension ,and the rest becomes a shot in the dark. Like the microsoft docs only showing you the interface members, and “go crazy!”

    I also haven’t found any explanation of how config.xml files are read and used.

    I’m very thankful for the articles though. The reason I write here is that these was the best articles I could find 🙂

  4. I’ve posted quite a lot of code here

    It’s not easy to get your head round at the beginning, that’s for sure. There’s good stuff in the MIIS walkthroughs if you want to go down the classic, sync engine extension route. It works exactly the same in FIM Sync. These days MS are only writing articles about portal based sync rules, so I wouldn’t expect any more extension coding doco from them.

Comments are closed.