Fatal Exception 0x80000003

[GloriousPtr]

Getting this fatal exception on my work (office) project.

raddebugger and target appears to be stuck while debugger is not connected, but when I connect the raddebugger (0.9.4 Alpha) to VS debugger and then run the target from raddebugger these exceptions popped.

I don't know how to reproduce it. This exception keeps popping as target program loads dlls and raddebugger tries to create .raddbg files

[ryanfleury]

Just to clarify, the debugger UI doesn’t exit after the exception message boxes appear, correct?

[GloriousPtr]

Yes it doesn't exit in fact after clicking "OK" enough times it loads and I can start debugging my target, only issue there is that some of my breakpoints wouldn't hit.

[ryanfleury]

Understood. Yeah, these crashes are from various conversion processes—some of them are failing. I’ll prioritize making the converter much more robust for the next couple of days.

As for the breakpoints—are these placed in files with line information? (Line information should be visualized as colors behind the line numbers)

If the converter failed for some of the DLLs you’re loading, and you’re trying to place breakpoints in those modules, then it makes sense that they’re not being hit. But if it looks like the breakpoints are placed on valid line info, then that could be a bug.

[GloriousPtr]

The issue was /DEBUG:FASTLINK
Need /DEBUG:FULL to make it work
Now everything works as expected.

[ryanfleury]

Oh, yes, that is definitely not supported. I’ll close this issue once I don’t crash when encountering it!

[GloriousPtr]

Sounds great!

[ryanfleury]

So, I couldn't end up reproducing the exact /DEBUG:FASTLINK access violation, so it is probably something more specific to the build in question - but I have tweaked things such that the converter processes no longer open message boxes like that, and will silently fail (though the debugger can still obtain information about the failure silently). We expect that there will many edge case, up to and including malformed or corrupt PDBs, and it's better in those cases for the converter to silently fail (this is partly the reason for the separate converter process design). I've got it on my list to visualize those failures more passively in the debugger UI, but closing this issue now, since these cases will no longer cause a UI problem like that.