Can't instrument DLL because of 3rd party library w/o debug symbols.
I'm trying to instrument a DLL for performance profiling, but the instrumentation process fails with messages as shown below. Since the messages refer to code in a third-party library, I'm not able to provide debug information, and I'm also not particularly interested in profiling that code anyway. Is there a way to exclude that code from instrumentation so that I can work with the rest of the DLL? Do I have to exclude each individual function exported from the library with the vsinstr /exclude switch or something?
Thanks,
Eric
Warning VSP2005 : Internal Instrumentation Error: The object '\dev\client\code\cpp\ThirdParty\lib\hook.lib(Hook_exp.obj)' was built without debug information.
Error VSP1014 : Code discovery analysis failed during processing image '|2'.
PRF0002: Instrumentation failed with these options: /u "x:\dev\build\client\Native\release\EditorAddin.dll" . Please check the output window for additional details.
I'm sorry to say, but for instrumenting binaries our current code really needs all of the debug symbols to work with. We're working on improving this for future releases. If you want a temporary workaround (I know that this isn't the best solution) you could, if possible, pull out just the code that you are interested in profiling and that you have symbols for into a seperate binary. Then you can use that for performance testing.
thanks,
Ian Huff
Wow - That makes this feature severely limited. I would image a lot of people developing reasonably sized applications would be using third party libraries. Any ETA on when this limitation will be resolved?
I tend to agree, though this limitation apparently only applies to static libraries, not other DLLs. For my particular case, I happened to also have access to a DLL version of the third-party library, and I was able to instrument my DLL with that configuration.
That triumph was short-lived, though, because the instrumented DLL crashed (access violation) somewhere in the runtime library when it got loaded, so I still haven't been able to do the profiling I would like to do.
--Eric
Terry,
Rest assured, we've heard from customers about the pain from this issue and we are looking at how we can best resolve it. Unfortuantly this issue is deep in how we handle instrumentation, so we don't have an ETA as to when this issue will be resolved.
Eric,
Do you have any more information about your program that is now crashing when profiling? If you can give me a little more information about your scenario perhaps I can help with diagnosing the crash.
Thanks,
Ian
Thanks, Ian, I would love some diagnostic help. This may be too specific a case for a general forum, but I'll let you decide if this should be handled in a different way.
I'm trying to profile a Word add-in written in C++, and that uses a minimal amount of ATL. When I start my profiling session, it launches Word, but my add-in fails to load. The COM Add-Ins dialog says it didn't load the add-in because of a runtime error. If I attach the debugger to WINWORD.EXE, and try to reload the add-in (by checking the box in the add-in dialog and clicking OK), then I can step into my DllMain. DllMain is pretty trivial -- it just calls the ATL DllMain. The code doesn't ever make it into the add-in's implementation of IDTExtensibility2::OnConnection though. Somewhere between DllMain and that function I get an Access Violation reading 0x44905a4f. The debugger stops in the thread _DllMainCRTStartup in msize.c at this line:
retval = (size_t)HeapSize(_crtheap, 0, pblock);
The instruction pointer isn't here, though (I get the green arrow instead of the yellow arrow). The callstack says I'm actually at VSPerf80.dll!01abce9a(). Frames below that are tagged as unreliable w/o debug information for VSPerf80.dll.
I should add that the non-instrumented add-in works as I expect. That is, it loads and runs fine.
Is that enough for you to go on?
Thanks,
Eric
P.S. Ever notice that the font size in this forum gets messed up if you paste something in the editor?
Eric,
One thing to try might be using the profiler in sampling mode as opposed to instrumentation mode. Sampling mode is a little less intrusive then instrumentation and usually collects a more reasonable data set. I would recommend giving sampling mode a try in your scenario.
Thanks,
Ian
Even we have a similar issue. Am not able to instrument our code as the third party lib does not have symbols built. Creating a separate binary for my code is difficult and that adds another layer for me as we are more interested in profiling our code in conjunction with the thirdparty lib.
Any workaround will be appreciated.
It seems to be creating a dll even after the error message. Will I get useful data if I profile using that dll?
In this situation, can I use PGO to optmize my code?
Thanks
Hi Ian,
what about this? Any new information?
Kind regards,
Daniel
Any update status on this problem?
Any update on this from the profiler team?
Also: Are there any workarounds out there other then pulling out the code you want to profile or the code that uses the library in question? Something that tells the profiler "No thanks I don't want to know whats going on in library xzy.lib" for example?
Any update on this? Maybe some hope for a fix in a upcoming version/service pack?
