Reversing a reverser

Two weeks ago, when I finally managed to get a 64bit machine and migrate to a 64bit OS, I installed for the first time Windows 7 64bits. Installation of a new OS is a terrifying experience, specially when moving to a new platform, some software that we're used to, ceases to function correctly, we need to reinstall tons of software, some we forget, some are no longer available. I think everyone has gone thru the process at least one time in their lives.

So, I was installing the tools of the trade, IDA being one of them and one of my favorite tools ever. As soon as I started IDA, I noticed that it failed loading the symbols of the target PE/PE+ file. What was going on? I reinstalled the tool, installed Microsoft debugging tools, and the symbols were resolved with Windbg but not with IDA.The weirder part of it, was that IDA was still asking me if I wanted to load the symbols, and yes, I answered affirmatively.I started debugging symbol loading, and everything worked fine. The problem was just within IDA.

I activated logging in symbol load, and I got this:

DBGHELP: new session: Thu May 19 16:11:28 2011
DBGHELP: Symbol Search Path: ¸Û¾
DBGHELP: No header for C:\Users\popo\Desktop\win7x86\logoncli.dll.  Searching for image on disk
DBGHELP: C:\Users\popo\Desktop\win7x86\logoncli.dll - OK
DBGHELP: ¸Û¾\logoncli.pdb - file not found
DBGHELP: ¸Û¾\dll\logoncli.pdb - file not found
DBGHELP: ¸Û¾\symbols\dll\logoncli.pdb - file not found
DBGHELP: C:\Users\popo\Desktop\win7x86\logoncli.pdb - file not found
DBGHELP: logoncli.pdb - file not found
DBGHELP: logoncli - export symbols
DBGHELP: closing session: Thu May 19 16:11:28 2011

The symbol search path had a weird string value. I checked the environment variables , and again everything was fine. I was irritated by now with IDA, because being such a great tool I couldn't get any clue of what was going on.
I searched all over the Internet and there was no answer for this problem anywhere, no clue in Hex-Rays blog. What the hell? Is it only me?
I started manipulating pdb.cfg and again, nothing.

One thing though that I noticed was that the symbols files were loaded if in the same directory than the object file, so for the first week I managed to go along by loading manually the .pdb and then copying it to the same directory of the executable.
Yesterday I asked myself, I'm I a reverser of a mouse? So I dug into reversing and debugging IDA.
This is what I found.

By the time IDA tries to initialize the symbols, the search path is corrupted. So I backtracked were was the path being set. This block of code tries to start-up a couple of components, and for the code to get the right values from _NT_SYMBOL_PATH or _NT_ALTERNATE_SYMBOL_PATH , it needed to successfully create one of this COM objects.

After getting the class ID of the COM object, all I needed to do was to go to my old XP and find out which executable file was being started.

The executable I found was a .dll file called msdia90.dll. All that's left to do is to grab this dll, copy it to my new machine and register it within the system:

regsvr32 msdia90.dll

And finally IDA worked its magic as always. Hurra!!...