Can't instrument DLL because of 3rd party library w/o debug symbols.

Question

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.

Answer 1

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

Answer 2

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?

Answer 3

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

Answer 4

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

Answer 5

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?

Answer 6

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

Answer 7

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

Answer 8

Hi Ian,

what about this? Any new information?

Kind regards,

Daniel

Answer 9

Any update status on this problem?

Answer 10

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?

Answer 11

Any update on this? Maybe some hope for a fix in a upcoming version/service pack?

Answer 12

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

OK, fast forward 3+ years and switching to Microsoft Visual Studio 2008, same question.

We are building an application that uses 3rd party DLLs that are not built for debugging. Can VS C++ build a project to profile "our" code (we don't care about profiling the 3rd party DLL)?

TIA,
Don

Answer 13

Hi Don,

Yes, we added support (it might've been in VS2008 SP1) to do instrumentation profiling on binaries that link against 3rd party libraries without PDB information.  This should just work without any actions required by you.  Are you having issues with doing this?

Regards,
Chris

Answer 14

Hi Chris,
I am using VS2008 version 9.0.21022.8RTM.  I am still not able to instrument linked 3rd party library without .pdb.  I am still getting

<small>Warning VSP2005 : Internal Instrumentation Error: The object '\intel\IPP\5.3.2.073\ia32\lib\ippsmerged.lib(\\svsfiler02\ipp_build\ipp\ipp53gold-20080204-5-3-0085-21\_obj\win32\s_lib\w7\mrg\psmulm6a6w7cn\psmulm6a6w7cn_split_w7_ownsMul_32f_I.obj)' was built without debug information.
Error VSP1033 : The file 'C:\Projects\...\objchk_wlh_x86\i386\xxxxx.dll' does not contain a recognized executable image.
</small>
Is there something for the instrumentation i need to turn on/off to be able to instrument it?

Regards,

-Christian

Answer 15

Hi Christian,

It appears that you do not have SP1 installed for VS2008.  Please try installing VS2008 SP1 and running through your scenario again.

Regards,

Chris

Answer 16

Hi Chris, Yes, SP1 did the trick. The tool just gave me warning VSP2005: that the external linked library does not have debug info, and it let me continue profiling my code. Now I don't have to stub out my linked 3rd party library. This is great... I love this performace tool, now! Thanks!! Great job Microsoft Team! -Christian

Answer 17

Hi Christian,

It seems that your answer has solved the problem for people using the team edition. I am, however, using the command-line (standalone) version of VSInstr and having the exact same problem. My code is built using VS2008 SP1, but the third party lib is provided as binary.

Any advice for this situation?

Thanks, cheers,

Geza