Mismatched tpsstool.dll and .pdb

[Shannon_P_]

I'm using VTune Amp XE 2015, build 367959 and am running into some problems instrumenting our code with tasks.

When we run the application under VTune, it crashes with a stack overflow in pinvm.dll. Without VTune, it runs fine.

The actual overflow stack has a bunch of tpsstool.dll entries in it. When I attempt to load symbols for  C:\Program Files (x86)\Intel\VTune Amplifier XE 2015\bin32\tpsstool.dll (in the Visual Studio 2012 debugger) and point it at the tpsstool.pdb found in C:\Program Files (x86)\Intel\VTune Amplifier XE 2015\bin32\runtime, I am told that "A matching symbol file was not found in this folder."

This leads me to believe that the .dll and .pdb aren't from the same build.

shannon

P.S. I don't blame tpsstool for the crash, I just thought you should be notified that the builds do not match. It would be convenient to see what's going on in there while debugging. It would also be nice to have the symbols for pinvm.dll for the same reason.

[olegmax]

Hi. I have Vtune 2013 and 2015upd1 both installed and, when profiling with 2015, application crashes, while with 2013 everything works fine.

When I try to debug, VS doesn't load tpsstool.pdb symbols for tpsstool.dll from 2015, even if I point to it directly.

[Vitaly_S_Intel]

Hi olegmax,

Which analysis type causes application crash on 2015, but goes fine on 2013? Does it lead to the same behavior on Basic Hotspots and Advanced Hotspots ?

[Bernard]

@Vitaliy

Does VTune handle its internal error by itself just like Intel Compiler? I have frequent VS 2013 debugger crashes which are probably due to VTune integration. When VS 2013 is running under Windbg and I try to use VS debugger to debug my code then crash occurs and windbg is not able to break in on any exception.

Thanks in Advance.

[Vitaly_S_Intel]

Hi ilyapolak!

VTune registers exception handler in VS process which is supposed to handle VTune crashes (though it actually may lead to handling all the crashes, not only caused by VTune). Is it what you meant by "handling internal error"?

Did I get you right that you're running Visual Studion under WinDbg and then try to debug your own application right from VS? Just interesting - what is the reason for doing that?

So, I hardly imagine how VTune can cause debugger crashes, but if there are no crashes without VTune integrated to VS, we definitely need to look at this.

[Bernard]

Hi Vitaliy,

Thank you for your response.

I observed the same behavior of VS debugger on two different laptops which are used for code development. When Intel Composer integration is uninstalled there is no any VS debugger crash. The failure only occurs when Intel Composer is integrated with VS 2013.

[Vitaly_S_Intel]

I remember there was an issue in compiler integration causing VS to crash, like the one posted here. So, that's likely not a VTune causing VS crashes on your system.

[Bernard]

>>>Did I get you right that you're running Visual Studion under WinDbg and then try to debug your own application right from VS? Just interesting - what is the reason for doing that?>>>

Yes I did it few times in order to catch VS debugger thread  crash by Windbg. I thought that faulted call stack inspection should give some clue. Unfortunately windbg caught only some CLR runtime exceptions which were not helpful in order to understand the root cause of the problem.

>>So, I hardly imagine how VTune can cause debugger crashes, but if there are no crashes without VTune integrated to VS, we definitely need to look at this>>>

​Yes it seems counter intuitive  and I need investigate it further on both my machines.

[Bernard]

Vitaly Slobodskoy (Intel) wrote:

I remember there was an issue in compiler integration causing VS to crash, like the one posted here. So, that's likely not a VTune causing VS crashes on your system.

Yes you are right that was not VTune. I did exactly what Steve Lionel suggested and now everything is working fine. There is no any further crashes of VS debugger.

Thank you.

[Peter_W_Intel]

I saw many discussions about VTune crash, we need to distinguish it from different reason:

1. Run program with VS debug, but without VTune - does it crash?

1.1. If it still crashes, uninstall VTune Amplifier, does it crash?

  - If no, need to investigate how VTune component impacts on VS debugger

  - If yes, need to investigate program itself.

1.2. If it doesn't crash  - it should be issue of VTune integration with VS/Debugger.

2. Follow 1.2 situation, as a workaround run VTune Amplifier standalone or command line. 

[Bernard]

I applied Steve's solution to my second notebook and VS debugger works correctly.

[Robert_L_Intel1]

Bob L. HUD (Intel) wrote:

Hi Shannon - It could be a coincidence, but I've discovered another issue with the exact same problem on Windows 7 x64.  In both cases, the NVidia* driver is on the faulting stack and is of the same version.  It might be worth upgrading the driver as a possible resolution while we continue to investigate the issue internally.  In your case, the base pointer is being used as a general-purpose register, so I can't make much sense of the stack other than to say that there are addresses which fall in the range of the driver.

Here, I believe, would be the latest driver for your system.

http://www.nvidia.com/download/driverResults.aspx/79890/en-us

Hi Shannon - I'm still waiting on final confirmation from the other investigation that matches yours exactly, but they tell me that a _downgrade_ of the NVidia* driver seems to have resolved the issue in two separate incidents so far.  If you have no dependency on the latest driver, I thought a downgrade might be something you would want to try as well.

Regards,

- Bob