Thanks for reporting this and that you used subst. That sort of detail is very important to reproducing and debugging the issue. We will try to reproduce this and fix it.
The reason that the name substitution worked in 2.76 and not 3.2 is that all the module data is stored in a monolithic data file. To speed up reading the module specific data, we broke it out into separate .imd files. To get the module name change work-around to fully work, you would need to modify it in the appropriate .imd file. The appropriate imd file name is referenced in the .tbp where you would have fixed the path.
Hopefully, we can identify the root cause and fix it soon.
to try your work-around I uninstalled CA 2.76 and installed the 3.2 again. Created a session. Used a script to replace the invalid
in the .imp and .imd files. Now CA can browse the DLLs and bring up the source code.
*NOTE*: the 3.2 adds an extra \ in front of the drive letter, thus
in the files. Looks like the SUBSTed drive is somehow forcefully converted to an UNC share name??
The \\v\ format of file system path is reported to us by the Microsoft API PsSetLoadImageNotifyRoutine. The reason we've had similar problems interpreting the module names in the past is the wide range of possible name formats.
Thank you very much for the level of detail you gave us. That helps immensely.
I'm glad to help. I will be happy when CA works on my machine. I guess many users face this problem.
From what I recall, Microsoft changed the PsSetLoadImageNotifyRoutine in Vista and later, to contain an extra pointer to a _FILE_OBJECT. This should perhaps give you the "real" file name of the loaded image, at least under Vista and later.
The path assigned by you to load the module is wrong check it