Build/Test Issues

Manually removing breakpoint that NCrunch set up crashes visual studio

Started by michaellogutov on 4,504 views

This bug actually an old one.

To reproduce:
[list=1]
  • Start NCrunch debug on failed test with "Break into first covering test" feature - the automatic breakpoint will be set by NCrunch
  • Wait for debug is fully started
  • Stop debug (with Stop button in toolbar) and while studio reverting back to normal mode manually remove breakpoint that was set by NCrunch (I use F9 key to do this) before NCrunch able to do it (this step is a bit tricky and require big solution to have time to react)


  • It gets me studio crash every time.

    I have Visual Studio 2015 Update 2 and nCrunch 2.19.0.4
    Hi,

    Thanks for sharing this issue.

    I haven't been able to recreate it myself, but I expect that it's likely to be the result of some kind of threading issue, so it probably shows more consistently in some scenarios than others.

    NCrunch has exception traps all over its handling of breakpoints, so I suspect this is blowing up somewhere inside VS itself. Is there any chance you can get a stack trace on the exception? It may be possible to do this if you have a debugger attached to the VS instance when it explodes.
    I wasn't able to get the callstack (attaching the debugger didn't help - the studio just restarts when crashed).
    The only thing I can provide - an error from event viewer:

    Faulting application name: devenv.exe, version: 14.0.25123.0, time stamp: 0x56f22f32
    Faulting module name: ntdll.dll, version: 6.3.9600.18233, time stamp: 0x56bb4e1d
    Exception code: 0xc0000374
    Fault offset: 0x000e6054
    Faulting process id: 0x2118
    Faulting application start time: 0x01d1919b8db1a937
    Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
    Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
    Report Id: 40cd37a0-fd92-11e5-8296-3085a98f2382
    Faulting package full name:
    Faulting package-relative application ID:
    Another thing - this could be related to Resharper (I've got it running all the time).
    michaellogutov wrote:Another thing - this could be related to Resharper (I've got it running all the time).


    I think it's become hard to find developer machines without Resharper installed these days :)

    Unfortunately, the VS debugger is far from perfect. I've noticed a range of rare edge cases that seem to crash it in different environments. It may also be that you're experiencing an intermittent crash that is debugger related, and it simply seems to coincide with the breakpoint adjustments in NCrunch. Unfortunately, the crash itself doesn't seem to point towards any code that I have the power to change, so I'm at a bit of a loose end on this problem right now. Do let me know if you find out anything more about it.

    Post a reply

    Log in to reply.