- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is painful.
I have a mixed-language program and ran the debugger. One of my Fortran subroutines has several entry points. I wanted to check the value of an input argument to be sure it was the same as the calling program's value. I held the mouse over the variable name, and nothing happened. (Usually, it shows the numeric value.) So I dragged that name into the Watch pane.
The system froze. Nothing responded to anything. Ctrl+Alt+Del did nothing. I tried it lots of times, and then got a blue screen.
Rebooted, and my desktop icons were in all the wrong places. My network did not work. Hours on the phone with three tech support guys, who tried everything. The restore points were corrupted.
They said I had to wipe my disk and reinstall everything. Ugh. Anyone who's used a computer knows bad news when it hears it. It's not nice to scream and weep in public -- but this was definitely the time.
I now have some of my stuff reinstalled, but the network still does not work. I'm not an expert in that, and it will take me several days of dumb trial and error before it works again. Fortunately, I had a backup copy of all my source files, so it could have been worse.
Be advised: if you use the debugger for a Fortran program, you have entered a minefield. Does the programming team know about this?
I have a mixed-language program and ran the debugger. One of my Fortran subroutines has several entry points. I wanted to check the value of an input argument to be sure it was the same as the calling program's value. I held the mouse over the variable name, and nothing happened. (Usually, it shows the numeric value.) So I dragged that name into the Watch pane.
The system froze. Nothing responded to anything. Ctrl+Alt+Del did nothing. I tried it lots of times, and then got a blue screen.
Rebooted, and my desktop icons were in all the wrong places. My network did not work. Hours on the phone with three tech support guys, who tried everything. The restore points were corrupted.
They said I had to wipe my disk and reinstall everything. Ugh. Anyone who's used a computer knows bad news when it hears it. It's not nice to scream and weep in public -- but this was definitely the time.
I now have some of my stuff reinstalled, but the network still does not work. I'm not an expert in that, and it will take me several days of dumb trial and error before it works again. Fortunately, I had a backup copy of all my source files, so it could have been worse.
Be advised: if you use the debugger for a Fortran program, you have entered a minefield. Does the programming team know about this?
Link Copied
- « Previous
-
- 1
- 2
- Next »
32 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does the debugger use a r0-driver for user-mode apps debugging at all?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not as far as I know. It is user-mode only.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Every thread partly executes in kernel mode when it calls Native API functions(implemented in ntoskernel).So it is very possible that some of the function's code will misbehave while executing in kernel mode and will bring down the whole system.Does the debugger use a r0-driver for user-mode apps debugging at all?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Of course, but in this case the reason of system fault and BSOD will be not the app's code but OS's, won't it? User-mode app just can't cause BSOD by itself. So, If the debugger is undoubtedly r3 only, there is nothing to debate.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Of course, but in this case the reason of system fault and BSOD will be not the app's code but OS's, won't it? User-mode app just can't cause BSOD by itself. So, If the debugger is undoubtedly r3 only, there is nothing to debate.
Did I write that reason of BSOD was app's fault?Misbehaved application will be terminated, but misbehaved kernel mode code even OS modules will BSOD the system.Every user mode thread has two stacks one for user-mode functions calls and one for kernel mode functions call when you debugg an app you can see the stub KiFastSystemCallEntry this iskernel mode entry point from the user mode part of thread.
Without crash dump file there is nothing to debate.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did I write that I don't know basic windows architecture? Why are you describing it?
There is nothing to debate at all, because r3 debugger can't cause BSOD.
There is nothing to debate at all, because r3 debugger can't cause BSOD.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did I write that user-mode debugger caused the BSOD? I have only described possible chain of events that might have caused the crash.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Crash is one thing. I can easily believe that some odd combination of WinAPI calls might trigger a problem there. But corruption of Windows that renders the system unbootable? Nope.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well I want to report thatVTune Amplifier caused damage to my system as well. I was trying to debug a Fortran code in visual studio 2010 when the debugger crashed and keeps crashing since then. No matter what I tries I always have an unstable debugging process. I tried to uninstall everything and re-install it but never worked! I am very frustrated with the damageVTune Amplifier has caused to my system. I got rid of VTune Amplifier(luckily I did not buy it just had it in trail mode). However, since then I was not been able to use vs2010 in debug mode and I lost three days trying to work something out without any success.
I would never recommend this harmful software"VTune Amplifier" to be used by anybody!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Was it system wide fault like BSOD or local process crash.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is a local process. I am not able to debug with vs2010 no more.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do not debug with VS 2010 it is not suitable for this.You must use windows debugger and collect local crash dump file.Install windbag and set it as a post-mortem debugger you can also tweak the settings in gflags.exe or even in debugger itself for what kind of exception debugger will break-in.
Do you have windows debugging tools installed?
It seems like VTune Amplifier caused some kind of unhandled exception probably Access Violation and was terminated.
Do you have windows debugging tools installed?
It seems like VTune Amplifier caused some kind of unhandled exception probably Access Violation and was terminated.
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
- « Previous
-
- 1
- 2
- Next »