- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The Problem is same as http://software.intel.com/en-us/forums/showthread.php?t=73204
I find the extra condition : DLL project and the extension name is not ".dll", 100% cause crashes when debuggingat the breakpoint
Now the only solution that I know is uninstalling the parallel debugger
I have tried:
There is the same problem in 11.1.060, butThere isn't the probelm in11.0.072
Win7 32(64)+ vs2008sp1 + 11.1.060(11.1.067)
Is this a known issue? I want another wayto solve this problem...
Thanks
I find the extra condition : DLL project and the extension name is not ".dll", 100% cause crashes when debuggingat the breakpoint
Now the only solution that I know is uninstalling the parallel debugger
I have tried:
There is the same problem in 11.1.060, butThere isn't the probelm in11.0.072
Win7 32(64)+ vs2008sp1 + 11.1.060(11.1.067)
Is this a known issue? I want another wayto solve this problem...
Thanks
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. Check if you have all project built with same unmixed compiler version 060. Still getting error, then go to Step 2. Are you using same compiler options when you switch compilers.
2. Start with the project built with compiler prior to 060 (051 or smthng, discarding files that have compiler bug), which comes clean while debugging.
Slowly, incude some set of DLL's to be built with 060, and notice if the crash comes while debugging. Then include more DLL's to build with 060.
If that is practical to handle given the multiple levels of DLL, that can narrow down the error location window.
In debugging environments that I worked, there is also a possibility of system or environment files interfering with the application locks/synchronization., causing deadlocks and crashes as well, though this might not be the case here.
If1. & 2.does not work out well, you may need to work with some system expert that has extensive knowledge of Process Monitoring tools , only in case its not caused by the compiler. But anyway, it may give some insight into the cause & nature of crash.
2. Start with the project built with compiler prior to 060 (051 or smthng, discarding files that have compiler bug), which comes clean while debugging.
Slowly, incude some set of DLL's to be built with 060, and notice if the crash comes while debugging. Then include more DLL's to build with 060.
If that is practical to handle given the multiple levels of DLL, that can narrow down the error location window.
In debugging environments that I worked, there is also a possibility of system or environment files interfering with the application locks/synchronization., causing deadlocks and crashes as well, though this might not be the case here.
If1. & 2.does not work out well, you may need to work with some system expert that has extensive knowledge of Process Monitoring tools , only in case its not caused by the compiler. But anyway, it may give some insight into the cause & nature of crash.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have not seen this. It would be nice if you can share your testcase projcet and step to reporduce the issue.

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