- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
My team works on a large code base a significant part of which is in Fortran. We recently upgraded to Intel(R) Visual Fortran Composer XE 2013 Update 3 Integration for Microsoft Visual Studio* 2012, 13.0.3624.11. After this we all are experiencing unbearable slowdowns when debugging the code. Whenever we try to debug Fortran or even just have a Fortran module on the call stack every debugger step through the code takes 10 or more seconds of full CPU load. Using Sysinternals Process Explorer I was able to see the call statck like one listed below. Note FEE.dll which is Intel(R) Fortran Expression Evaluator 13.0.2225.2.
I need help with this urgently as the entire team cannot work normally because of this.
msdia110.dll!DllGetClassObject+0x2c060
msdia110.dll!DllGetClassObject+0x2c1ff
msdia110.dll!DllGetClassObject+0x2c278
msdia110.dll!DllGetClassObject+0x2b3b7
msdia110.dll!DllGetClassObject+0x3536e
msdia110.dll!DllGetClassObject+0x1093a
FEE.dll!DllGetClassObject+0x205f7
FEE.dll!DllGetClassObject+0x20972
FEE.dll!DllGetClassObject+0xb18e
FEE.dll!DllGetClassObject+0xb4fe
FEE.dll!DllGetClassObject+0x9cc4
FEE.dll!DllGetClassObject+0x505f
FEE.dll!DllGetClassObject+0x655c
FEE.dll!DllGetClassObject+0x760a
FEE.dll!DllGetClassObject+0x7e14
FEE.dll!DllGetClassObject+0x8354
FEE.dll!DllGetClassObject+0x307e2
VSDebugEng.dll!DkmDllEnsureInitialized+0x8169c
VSDebugEng.dll!ProcDkmFree+0x1989
VSDebugEng.dll!ProcDkmFree+0x1776
VSDebugEng.dll!DkmDllEnsureInitialized+0x857e5
VSDebugEng.dll+0xc25d
VSDebugEng.dll!DkmDllUninitialize+0x24a
ntdll.dll!RtlInitializeExceptionChain+0x85
ntdll.dll!RtlInitializeExceptionChain+0x58
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes agree with you that we should wait for response.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One of my colleagues who specializes in debugging is working on this issue in premier support.
Annalee
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've uploaded the source code project and build instructions to Premier tech support. Waiting for response.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have the same issue in our mixed C++/Fortran application. Installed Composer Update 4, but the problem persists.
Using xperf, I found that FEE.dll uses a lot of CPU (~95%) calling into MSDIA110.dll!CDiaEnumTraversal, which again spends a lot of time in MSDIA110.dll!NameMatcher::match.
Any suggestions on fixes or workarounds for this is very much appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>Using xperf, I found that FEE.dll uses a lot of CPU (~95%) calling into MSDIA110.dll!CDiaEnumTraversal, which again spends a lot of time in MSDIA110.dll!NameMatcher::match.
Do you have a lot of variables in your Watch window(s)?
If so, what happens if you remove all of them? (then set the ones you really need)
Do you have any conditional breaks set?
if so, what happens if you remove (all of) them?
One more stab in the dark, try turning off intelisense (thing that shows contets of variable when hovering mouse over a variable).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
fee.dll is the Fortran debug expression evaluator. The indications here are that it is calling back into Visual Studio to look up names. We don't typically see a lot of overhead from this.
It looks to me as if you are getting appropriate assistance through Premier Support issue 696480.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for the hints, but no luck..
jimdempseyatthecove wrote:
Do you have a lot of variables in your Watch window(s)?
If so, what happens if you remove all of them? (then set the ones you really need)
Nothing in the Watch window (or Memory), still slow.
jimdempseyatthecove wrote:
Do you have any conditional breaks set?
None
jimdempseyatthecove wrote:
One more stab in the dark, try turning off intelisense (thing that shows contets of variable when hovering mouse over a variable).
No effect..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>Using xperf, I found that FEE.dll uses a lot of CPU (~95%) calling into MSDIA110.dll!CDiaEnumTraversal, which again spends a lot of time in MSDIA110.dll!NameMatcher::match.>>>
Why decision to use Xperf on stalled thread.Usually when narrowing the problem down to some routine(s) next step could be single stepping through the code combined with execution tracing and the worst thing trying to understand the problem at assembly code level.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
iliyapolak wrote:
Why decision to use Xperf on stalled thread.Usually when narrowing the problem down to some routine(s) next step could be single stepping through the code combined with execution tracing and the worst thing trying to understand the problem at assembly code level.
I'm sorry, but you seem to misunderstand the issue here. I try to single step, in Visual Studio, from my C++ code to my Fortran code. Visual Studio stalls for more than 1 minute before hitting the breakpoint in the Fortran code, where almost all the time is spent in FEE.dll (according to xperf).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sergey Kostrov wrote:
Is it an UI problem or something else?
Unfortunately, it does not seem to be an UI problem. The messages logged with Spy++ are the same for fast-to-debug and a slow-to-debug programs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No I understand your problem pretty well.The sentence related to single stepping is about attaching external debugger to stalled VS debugger thread.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>No I understand your problem pretty well.The sentence related to single stepping is about attaching external debugger to stalled VS debugger thread.>>>
It should be done either by Intel devs or by MS escalation engineers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This issue is being handled by Intel engineering through Intel Premier Support.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I just came across this thread since I'm having the same problem, cf. http://software.intel.com/de-de/forums/topic/392877 . I've got also a premier support thread running and found out that renamig
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Packages\Debugger\FEE.vsdconfig
solves the performance issues. The drawback seems to be that the C/C++ expression-evaluator "knows" only uppercase variable and the C/C++ style arrays and struct. But at least you can debug the program again...
regards
Tobias
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for updating.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, that disables the Fortran debug expression evaluator.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Steve: in my case after disabling the FEE I regain debugging speed immediately. This highly indicates a performance bug in the FEE.dll as already indicated in this thread.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page