- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I updated IVF Composer XE on my machine with w_fcompxe_2011.10.325.exe (Build 10) about a month ago, which updated my IDE to the VS2010 Shell bundled with the compiler (previously, I was utilizing only the VS2008 Shell).
All my debugging activity for my current project had been proceeding smoothly, but yesterday (for no apparent reason), the Locals and Watch 1 windows no longer appear during a debugging session (I did not change any of the project properties).
Interestingly, I am still given the option to utilize the VS2008 Shell via my Windows 7 Start button, and when I begin a debugging session in that environment, the Locals and Watch 1 windows appear as usual, with all variables/values displayed correctly. (Build 10 of the IVF Composer XE is also utilized.)
Before contacting this support forum, I tried updating to w_fcompxe_2011.11.344.exe (Build 11), but the same issue occurs, even when I create a completely new folder and project (with the same files).
I want to emphasize that I am performing these debugging tests with error-free code, which executes perfectly when I select the 'Start Without Debugging' option from the Debug menu.
When in VS2010, the following comments appear in the Output window when I begin a debugging session:
'Tester.exe': Loaded 'C:\\Users\\Jeffrey\\Desktop\\IVF_VS_10\\Tester\\Debug\\Tester.exe', Symbols loaded.
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\ntdll.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\kernel32.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\KernelBase.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\imagehlp.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\msvcrt.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\advapi32.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\sechost.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\rpcrt4.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\sspicli.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\cryptbase.dll', Cannot find or open the PDB file
All my debugging activity for my current project had been proceeding smoothly, but yesterday (for no apparent reason), the Locals and Watch 1 windows no longer appear during a debugging session (I did not change any of the project properties).
Interestingly, I am still given the option to utilize the VS2008 Shell via my Windows 7 Start button, and when I begin a debugging session in that environment, the Locals and Watch 1 windows appear as usual, with all variables/values displayed correctly. (Build 10 of the IVF Composer XE is also utilized.)
Before contacting this support forum, I tried updating to w_fcompxe_2011.11.344.exe (Build 11), but the same issue occurs, even when I create a completely new folder and project (with the same files).
I want to emphasize that I am performing these debugging tests with error-free code, which executes perfectly when I select the 'Start Without Debugging' option from the Debug menu.
When in VS2010, the following comments appear in the Output window when I begin a debugging session:
'Tester.exe': Loaded 'C:\\Users\\Jeffrey\\Desktop\\IVF_VS_10\\Tester\\Debug\\Tester.exe', Symbols loaded.
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\ntdll.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\kernel32.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\KernelBase.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\imagehlp.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\msvcrt.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\advapi32.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\sechost.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\rpcrt4.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\sspicli.dll', Cannot find or open the PDB file
'Tester.exe': Loaded 'C:\\Windows\\SysWOW64\\cryptbase.dll', Cannot find or open the PDB file
Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Enter debugging mode, say by setting a break point and running your program till the breakpoint is hit, then choose Debug > Windows > Local and Debug > Windows > Watch > Watch 1.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, IanH, that works regarding recovering the Locals and Watch 1 windows. Thank you.
New Issues:
1. When debugging, I have noticed that the 'cube' symbols to the left of the variables that appear in the Locals window look different -- they now look like little rectangles with a small '1' enclosed by a box in the lower-left corner of the rectangle. These appear next to every variable listed in the locals window. They are noticeably different from the 3-D colored 'cube' symbols, which were displayed in the Locals window of VS2010 on my machine until yesterday.
When I debug within VS2008, the 'cube' symbols look normal -- 3-D in appearance and colored.
Also, I am still getting the same 'error' comments in the Output window regarding PDB files (these comments never occurred in VS2008 nor in VS2010, until yesterday).
2. When I debug and jump into some subroutines, I now get (upon entering past the subroutine argument list) a new tab appearing in the IDE, indicating 'No Source Available' with the following error messages:
Locating source for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'. Checksum: MD5 {0 55 b6 7f a5 d5 31 6a 95 45 9e 4c 67 c 41 a6}
The file 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm' does not exist.
Looking in script documents for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'...
Looking in the projects for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'.
The file was not found in a project.
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\vc7\atlmfc'...
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\vc7\crt'...
The debug source files settings for the active solution indicate that the debugger will not ask the user to find the file: f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm.
The debugger could not locate the source file 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'.
At this point, the debug session just hangs up, and I have to manually terminate it.
Interestingly, if I set a break point farther into the subroutine, I can 'Continue' to it without first entering into the subroutine by stepping a line at a time, and the local variables/values are accessible.
None of these issues occur when I execute the same build (w_fcompxe_2011.11.344.exe) within VS2008 on the exact same project files.
Are there issues with the recent inclusion of the VS2010 Shell into IVF Composer XE?
I am wondering whether Steve L., the most revered one, might be able to weigh in on these matters.
New Issues:
1. When debugging, I have noticed that the 'cube' symbols to the left of the variables that appear in the Locals window look different -- they now look like little rectangles with a small '1' enclosed by a box in the lower-left corner of the rectangle. These appear next to every variable listed in the locals window. They are noticeably different from the 3-D colored 'cube' symbols, which were displayed in the Locals window of VS2010 on my machine until yesterday.
When I debug within VS2008, the 'cube' symbols look normal -- 3-D in appearance and colored.
Also, I am still getting the same 'error' comments in the Output window regarding PDB files (these comments never occurred in VS2008 nor in VS2010, until yesterday).
2. When I debug and jump into some subroutines, I now get (upon entering past the subroutine argument list) a new tab appearing in the IDE, indicating 'No Source Available' with the following error messages:
Locating source for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'. Checksum: MD5 {0 55 b6 7f a5 d5 31 6a 95 45 9e 4c 67 c 41 a6}
The file 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm' does not exist.
Looking in script documents for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'...
Looking in the projects for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'.
The file was not found in a project.
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\vc7\atlmfc'...
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\vc7\crt'...
The debug source files settings for the active solution indicate that the debugger will not ask the user to find the file: f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm.
The debugger could not locate the source file 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'.
At this point, the debug session just hangs up, and I have to manually terminate it.
Interestingly, if I set a break point farther into the subroutine, I can 'Continue' to it without first entering into the subroutine by stepping a line at a time, and the local variables/values are accessible.
None of these issues occur when I execute the same build (w_fcompxe_2011.11.344.exe) within VS2008 on the exact same project files.
Are there issues with the recent inclusion of the VS2010 Shell into IVF Composer XE?
I am wondering whether Steve L., the most revered one, might be able to weigh in on these matters.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FWIW: I have always seen the following behaviours with VS2010 with SP1 - what you are describing is situation normal and I suspect have more to do with Visual Studio than the integration. Why things would suddenly change to situation normal after a month is what's odd.
Is it a little "1" or a little "i"? In those rare, quieter moments I often pause to contemplate this. The icons relate to the nature of the thing being displayed - is it a variable, an aggregate, a component, with the division between categories probably influenced by the VC++/.NET "heritage" of the debugger.
The pdb messages are a harmless consequence of you not having the symbol files for the Windows DLL's on your machine (or a suitable symbol server). Only relevant if your debugging takes you into that dark realm of understanding the interaction between your Fortran program and the base operating system. I'd suggest its best and simplest to ignore, but for the record symbol settings are under Tools > Options then choose the Debugging > Symbols category. From the modules window (Debug > Windows > Modules) you can right click on a module and change its Automatic Symbol Load Settings (next time you run you then get a different harmless message - but don't turn off symbols for the module that corresponds to your own program's exe though, or debugging will be somewhat harder.)
chkstk is a Microsoft provided routine that touches memory pages on the stack that belong to large arguments (arrays, etc). This is to ensure that the Windows mechanism for automatic, progressive committing of memory pages backing the stack works as designed. The VS2010 shell doesn't come with the source to the Microsoft C runtime, hence the error. Your debugger session shouldn't have hung (it doesn't here...) - it's just waiting for you to nominate what to do next (display disassembly,etc - do you see links/a check box in the pane that's advising you that the source couldn't be found? If you press F10 does the program's current location in that window update?) . Shift F-11 will instruct the debugger to run until it is back in the context that called chkstk, alternatively you could can just step through it (F10), or as you've found set a break-point on a later statement in the Fortran source and run up to it. There is a way of telling VS not to bother stepping into chkstk (or any specific function) - see here - you create a string value in the relevant registry key with a name of your chosing and a value of "_chkstk".
Is it a little "1" or a little "i"? In those rare, quieter moments I often pause to contemplate this. The icons relate to the nature of the thing being displayed - is it a variable, an aggregate, a component, with the division between categories probably influenced by the VC++/.NET "heritage" of the debugger.
The pdb messages are a harmless consequence of you not having the symbol files for the Windows DLL's on your machine (or a suitable symbol server). Only relevant if your debugging takes you into that dark realm of understanding the interaction between your Fortran program and the base operating system. I'd suggest its best and simplest to ignore, but for the record symbol settings are under Tools > Options then choose the Debugging > Symbols category. From the modules window (Debug > Windows > Modules) you can right click on a module and change its Automatic Symbol Load Settings (next time you run you then get a different harmless message - but don't turn off symbols for the module that corresponds to your own program's exe though, or debugging will be somewhat harder.)
chkstk is a Microsoft provided routine that touches memory pages on the stack that belong to large arguments (arrays, etc). This is to ensure that the Windows mechanism for automatic, progressive committing of memory pages backing the stack works as designed. The VS2010 shell doesn't come with the source to the Microsoft C runtime, hence the error. Your debugger session shouldn't have hung (it doesn't here...) - it's just waiting for you to nominate what to do next (display disassembly,etc - do you see links/a check box in the pane that's advising you that the source couldn't be found? If you press F10 does the program's current location in that window update?) . Shift F-11 will instruct the debugger to run until it is back in the context that called chkstk, alternatively you could can just step through it (F10), or as you've found set a break-point on a later statement in the Fortran source and run up to it. There is a way of telling VS not to bother stepping into chkstk (or any specific function) - see here - you create a string value in the relevant registry key with a name of your chosing and a value of "_chkstk".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IanH:
Thank you for the further information which you have provided -- you are obviously very knowledgeable.
Unfortunately, I am an engineer/physicist, responsible for developing programmed solutions to physical problems in terms of algorithms (based upon solution of differential equations, tensor analysis, etc.) expressed in FORTRAN -- I am not a computer scientist nor a PC technician. Thus, I am able to follow only about half of what you discuss. I miss the late 1980s and early 1990s, when I did all my programming on VAX VMS-based machines -- the interactive debugger was very stable and reliable. It is disappointing to update my version of IVF Composer XE 2011 to a build that utilizes VS2010, and then finding it necessary to revert to VS2008 in order to do my development work because of the problems cited above.
I am still hoping that someone from Intel can investigate this issue and offer simple suggestions for corrective action (i.e., so that my IDE experience in VS2010 is at least as good as it currently is in VS2008). I truly appreciate your assistance, though.
Thank you for the further information which you have provided -- you are obviously very knowledgeable.
Unfortunately, I am an engineer/physicist, responsible for developing programmed solutions to physical problems in terms of algorithms (based upon solution of differential equations, tensor analysis, etc.) expressed in FORTRAN -- I am not a computer scientist nor a PC technician. Thus, I am able to follow only about half of what you discuss. I miss the late 1980s and early 1990s, when I did all my programming on VAX VMS-based machines -- the interactive debugger was very stable and reliable. It is disappointing to update my version of IVF Composer XE 2011 to a build that utilizes VS2010, and then finding it necessary to revert to VS2008 in order to do my development work because of the problems cited above.
I am still hoping that someone from Intel can investigate this issue and offer simple suggestions for corrective action (i.e., so that my IDE experience in VS2010 is at least as good as it currently is in VS2008). I truly appreciate your assistance, though.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is not clear to me which issue needs investigating. If it is simply that one of the debugging windows has disappeared, you may have unintentionally closed it. Once in the debugger, select Debug > Windows and then select the type of window that is missing. It will reappear.
Microsoft is continually fiddling with the user interface and appearance of Visual Studio. You will probably not like what they have done in VS2012 regarding appearance - you may think your monitor has gone on the fritz.
Microsoft is continually fiddling with the user interface and appearance of Visual Studio. You will probably not like what they have done in VS2012 regarding appearance - you may think your monitor has gone on the fritz.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
I have submitted this issue to Intel Premier Support: #680952
If you are willing review this issue, please consult the Issue Details for information on my latest problems.
Quite honestly, I have more often received better help from this forum that that resource.
At this point, I am just seeking to get acceptable performance within the VS2010 Shell IDE for my development work. For the time being, I am continuing to work in the VS2008 Shell IDE -- I was able to preserve both options when I installed the latest update of IVF Composer XE 2011 (w_fcompxe_2011.11.344.exe).
I would appreciate any attention which you might be able to provide to this situation.
I have submitted this issue to Intel Premier Support: #680952
If you are willing review this issue, please consult the Issue Details for information on my latest problems.
Quite honestly, I have more often received better help from this forum that that resource.
At this point, I am just seeking to get acceptable performance within the VS2010 Shell IDE for my development work. For the time being, I am continuing to work in the VS2008 Shell IDE -- I was able to preserve both options when I installed the latest update of IVF Composer XE 2011 (w_fcompxe_2011.11.344.exe).
I would appreciate any attention which you might be able to provide to this situation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It looks to me as if you got fine support through Intel Premier Support, though I see that the support engineer did not know that those PDB messages are informational and can be ignored. They're only of interest if you want to debug Windows system DLLs, in which case you can download PDB info for them from Microsoft.
What are you unhappy with?
What are you unhappy with?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From my earlier post:
2. When I debug and jump into some subroutines, I now get (upon entering past the subroutine argument list) a new tab appearing in the IDE, indicating 'No Source Available' with the following error messages:
Locating source for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'. Checksum: MD5 {0 55 b6 7f a5 d5 31 6a 95 45 9e 4c 67 c 41 a6}
The file 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm' does not exist.
Looking in script documents for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'...
Looking in the projects for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'.
The file was not found in a project.
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\vc7\atlmfc'...
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\vc7\crt'...
The debug source files settings for the active solution indicate that the debugger will not ask the user to find the file: f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm.
The debugger could not locate the source file 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'.
At this point, the debug session just hangs up, and I have to manually terminate it.
Interestingly, if I set a break point farther into the subroutine, I can 'Continue' to it without first entering into the subroutine by stepping a line at a time, and the local variables/values are accessible.
None of these issues occur when I execute the same build (w_fcompxe_2011.11.344.exe) within VS2008 on the exact same project files.
I would like to work exclusively with the new compiler build in VS2010 -- I should not have to revert to VS2008 to get stable and reliable IDE performance for development work.
2. When I debug and jump into some subroutines, I now get (upon entering past the subroutine argument list) a new tab appearing in the IDE, indicating 'No Source Available' with the following error messages:
Locating source for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'. Checksum: MD5 {0 55 b6 7f a5 d5 31 6a 95 45 9e 4c 67 c 41 a6}
The file 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm' does not exist.
Looking in script documents for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'...
Looking in the projects for 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'.
The file was not found in a project.
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\vc7\atlmfc'...
Looking in directory 'C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\vc7\crt'...
The debug source files settings for the active solution indicate that the debugger will not ask the user to find the file: f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm.
The debugger could not locate the source file 'f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\chkstk.asm'.
At this point, the debug session just hangs up, and I have to manually terminate it.
Interestingly, if I set a break point farther into the subroutine, I can 'Continue' to it without first entering into the subroutine by stepping a line at a time, and the local variables/values are accessible.
None of these issues occur when I execute the same build (w_fcompxe_2011.11.344.exe) within VS2008 on the exact same project files.
I would like to work exclusively with the new compiler build in VS2010 -- I should not have to revert to VS2008 to get stable and reliable IDE performance for development work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I haven't encountered that issue and I switch back and forth between the VS environments often. It sounds as if you did a "step into" once into your procedure, and that might step into the chkstk library routine. If you find yourself in that situatiion, just click the "step out" button.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your debugger isn't hung, it is waiting for user input.
The attached registry script will stop the VS2010 debugger from ever stepping into any routine with a linker name of _chkstk. You can see what it does (creates a single string value in a particular location in the registry as per the blog post I linked to earlier) by inspecting it in a text editor. Double clicking it should install it - admin privileges will be required.
chkstk+fix.reg
(There may be a VS2010 debugger setting that automatically skips over routines with missing source (the default for this setting is probably what has changed from VS2008), but I'm not aware of it.)
The attached registry script will stop the VS2010 debugger from ever stepping into any routine with a linker name of _chkstk. You can see what it does (creates a single string value in a particular location in the registry as per the blog post I linked to earlier) by inspecting it in a text editor. Double clicking it should install it - admin privileges will be required.
chkstk+fix.reg
(There may be a VS2010 debugger setting that automatically skips over routines with missing source (the default for this setting is probably what has changed from VS2008), but I'm not aware of it.)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page