16

Is there any way of detecting that a debugger is running in memory?

and here comes the on Form Load pseudocode.

if debugger.IsRunning then
Application.exit
end if

Edit: The original title was "Detecting an in memory debugger"

OrElse
  • 9,709
  • 39
  • 140
  • 253

2 Answers2

33

Try the following

if ( System.Diagnostics.Debugger.IsAttached ) {
  ...
}
JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
5

Two things to keep in mind before using this to close an application running in the debugger:

  1. I've used a debugger to pull a crash trace from a commercial .NET application and send it to the company where it was subsequently fixed with a thank you for making it easy and
  2. That check can be trivially defeated.

Now, to be of more use, here's how to use this detection to keep func eval in the debugger from changing your program state if you have a cache a lazily evaluated property for performance reasons.

private object _calculatedProperty;

public object SomeCalculatedProperty
{
    get
    {
        if (_calculatedProperty == null)
        {
            object property = /*calculate property*/;
            if (System.Diagnostics.Debugger.IsAttached)
                return property;

            _calculatedProperty = property;
        }

        return _calculatedProperty;
    }
}

I've also used this variant at times to ensure my debugger step-through doesn't skip the evaluation:

private object _calculatedProperty;

public object SomeCalculatedProperty
{
    get
    {
        bool debuggerAttached = System.Diagnostics.Debugger.IsAttached;

        if (_calculatedProperty == null || debuggerAttached)
        {
            object property = /*calculate property*/;
            if (debuggerAttached)
                return property;

            _calculatedProperty = property;
        }

        return _calculatedProperty;
    }
}
Sam Harwell
  • 97,721
  • 20
  • 209
  • 280
  • That's a cool idea - but it changes the flow of your program when running under a debugger, so you're no longer debugging the code that you use in release. IMHO it would be better in most cases to provide a non-cached variant of the property (inside #if DEBUG so it's not built into releases) that you can use in the debugger to examine the value, leaving the "real" property working the same way in both debug & release builds. – Jason Williams Aug 25 '09 at 20:01
  • @Jason: yes and no. In this case, all methods called to evaluate the property are pure (no side effects regardless of when called), so I was actually ensuring that this held for properties as well from the application's perspective. – Sam Harwell Aug 25 '09 at 20:20
  • Do you think this approach is valid if you want to create a library that only works on debug mode from visual studio? I want to create a library that is free to test from visual studio but cannot be included in an application built on release mode – Jose Manuel Ojeda Sep 30 '18 at 15:25