Develop Reference

C#: Object is both null and not null

I'm getting some extremely weird behavior. An object appears to be null and not null at the same time, and a statement is getting skipped. I'm probably being an idiot, but if it's my fault I don't see it. I'm building using Visual Studio 2008 on a Windows 7 SP1 OS.
public void ReadTrendData(OpcDriver opcDriver)
{
if (opcDriver != null)
{
int a = 1;
}
if (opcDriver == null)
{
Exception ex = new Exception("Null OPC driver received by ReadTrendData()");
throw ex;
}
The opcDriver object is successfully created and passed in to this method. When I step through, the "int a = 1" statement is executed. Then, in the next if block, execution gets to the "throw ex" statement without executing the line above that creates the ex object. So, ex is null and throwing null gives me an access violation exception.
Do you have any idea what could be happening here?
A couple of members of the OpcDriver class are instances of classes from a 15-year-old ungauranteed, unsupported sample library that uses COM to interface with an OPC (OLE for Process Control) program. The only thing I can think of is that somewhere in the bowels of that library something grotesque is happening, but I can't think how this can be possible.
Thank you.

You should try on newer visual studio build. I got almost the same problem on 2008 and 2012 versions. It's a visual studio compile time bug. You should check your build option, if you selected "release" mode you should check back to debug and try again.

To sum up, it probably the problem's root is wrong operator overloading (== and/or !=). The test
if (Object.ReferenceEquals(opcDriver, null))
works as expected.

How to prevent break on specific exception if it's handled

Normally I want the debugger to break on ArgumentOutOfRangeException.
But within my try catch(ArgumentOutOfRangeException) that exception is already handled and so I want the debugger to not break.
I tried the DebuggerStepThrough attribute, but it still breaks.

You can do this by setting the debugger to break on user unhandled exceptions.
Go to Debug -> Exceptions, Common Language Runtime Exceptions, de-tick (uncheck) the Thrown box. Of course you can get very precise with what you want to break on by drilling down into that list. Be aware that this setting takes effect across the whole solution, you can't set it per class or method. If you do want to be more selective per method, then consider using compile directives to not include that bit of code during debug time.
As for the DebuggerStepThrough attribute, that is to prevent breaking on break points, nothing to do with breaking on exceptions.

You should check your visual studio isn't set to break on all exceptions
On the Debug menu, click Exceptions.
In the Exceptions dialog box, select Thrown for an entire category of exceptions,
for example, Common Language Runtime Exceptions.
Microsoft Visual Studio Help

There is a way. First disable debugging code that is not yours. Go to Tools > Options > Debugging > General > select "Enable Just My Code (Managed only)". Now tell the debugger that this one function is not part of your code with DebuggerNonUserCodeAttribute:
[System.Diagnostics.DebuggerNonUserCode()]
private void FunctionThatCatchesThrownException()
{
try
{
throw new ArgumentOutOfRangeException();
}
catch (ArgumentOutOfRangeException ex)
{
//...
}
}
If an exception (some other than ArgumentOutOfRangeException) gets out of the function debugger will catch it as usual, but the location of interception will be where the function is called.

How to make C# application crash

I want to test if my application crash dump can be debugged. But firstly, I need to generate a crash dump of my application. I'm using C# to code my app, and have tried with many exceptions and unsafe code etc. but don't get it.
Thanks!
Edit: Sorry, Just forgot something, I'm making the application with Unity3D, which handles exceptions for me automatically.
Edit 2: Thanks all for your answers. I've tested your suggestions in a standard C# application and it all works fine, but not in my Unity3D application (written with C#). It seems like Unity3D requires more effort to cause a crash, I might email Unity3D to get a answer. I will post here if I get it. Cheers!

The following will provide an unhandled exception and will ask for you to choose a debugger:
System.Diagnostics.Debugger.Launch()

StackOverflowException is a badass:
void PerformOverflow()
{
PerformOverflow();
}
Usage:
PerformOverflow();

Throw an exception :)
throw new Exception("Your exception here!");

For C# in Unity3D
There is UnityEngine.Diagnostics.Utils.ForceCrash (in Unity 2018.3)
This can be used with one of the following ForcedCrashCategory enum parameter:
AccessViolation
Cause a crash by performing an invalid memory
access.The invalid memory access is performed on each platform as
follows:
FatalError
Cause a crash using Unity's native fatal error
implementation.
Abort
Cause a crash by calling the abort() function.
PureVirtualFunction
Cause a crash by calling a pure virtual function
to raise an exception.
For older versions of Unity:
UnityEngine.Application.ForceCrash(int mode)
For even older versions (Unity 5):
UnityEngine.Application.CommitSuicide(int mode)
From my experience, mode 0 causes a "unity handled" crash (where the Unity crash dialog appears), and mode 2 causes a "hard" crash where the Windows error dialog appears.
This seems consistent with this post by Smilediver on mode:
0 - will simulate crash, 1 - will simulate a fatal error that Unity
has caught, 2 - will call abort().
(These methods are not documented as they were intended for Unity's internal use. They may also be marked [Obsolete] depending on your Unity version.)

Well. The only good 100% way actualy crash CLR is to inject a native exception into the managed world.
Calling the Kernel32.dll's RaiseException() directly will immediately crash ANY C# application, and Unity Editor as well.
[DllImport("kernel32.dll")]
static extern void RaiseException(uint dwExceptionCode, uint dwExceptionFlags, uint nNumberOfArguments, IntPtr lpArguments);
void start()
{
RaiseException(13, 0, 0, new IntPtr(1));
}
Happy crashing. Please note that in order to debug native and managed, you will need two instances of Visual Studio running. If you are developing native P/INVOKE plugin, set up it that Visual Studio Instance 1 is native debugger and uses Unity or your C# program as a Host program, and you attach to the Host program from another Visual Studio Instance.

Another option is to call
System.Environment.FailFast("Error happened")

A surefire way to do it is as follows:
ThreadPool.QueueUserWorkItem(new WaitCallback(ignored =>
{
throw new Exception();
}));
All the others can be handled by the top level ApplicationDomain.OnUnhandledException and the like.
This one will kill it dead (assuming .NET 2.0+, and not using 'legacyUnhandledExceptionPolicy': http://msdn.microsoft.com/en-us/library/ms228965.aspx).

None of the answers crashed my app the way I was looking for. So here is the approach that worked for me.
private void Form1_Load(object sender, EventArgs e)
{
object p = 0;
IntPtr pnt = (IntPtr)0x123456789;
Marshal.StructureToPtr(p, pnt, false);
}

public void Loop()
{
Loop();
}
//call this
Loop();

I think there was a code in earlier unity versions like
Application.commitSuicide(number Input);
Now it is replaced by
Application.ForceCrash(number input);
Till this point, I dont know what different numbers do in number input, but for me,
Application.ForceCrash(1);
does the job.

you could also divide by zero,
z = 0;
int divide = 1 / x;

int[] x = {0};
int blah = x[2];
will cause an exception just as well

It's easy enough to reproduce if you try to transform a null game object. For example, like this:
public static GameObject gameObjectCrash;
public void GenerateCrash()
{
gameObjectCrash.transform.rotation = Quaternion.Euler(90, 0, 0);
}

Use below code to close the application.
Environment.Exit(1);
Exit needs a parameter called exitcode. If exitcode=0 means there was no error. Supply a non-zero exit code to to reflect an error.

Application hangs only when breakpoint is triggered, .NET, C#, Visual Studio

I refactored my application a while ago and since then I've been having problems with debugging using Visual Studio 2010.
My application works as expected while not debugging (not stepping through the application. An attached debugger does not cause any issues). However, when a breakpoint is triggered and I start to step through the app, Visual Studio and the app both hang after at most 3-4 steps.
To emphasize this point even more: It works well with my customers and regardless of whether I start it from Visual Studio or stand-alone - as long as no break point is triggered.
It does not matter where in the code I place the break point.
IDE: Visual Studio 2010 x64
Platform: .NET 4.0
The refactoring included a lot of cross-thread calls to BeginInvoke - all channeled through the following method:
public static void BeginInvokeIfRequired(this Control control, Action action)
{
if (control.InvokeRequired)
{
control.BeginInvoke(action);
}
else
{
action.Invoke();
}
}
There is not a single call to Control.Invoke() in the project.
Is there something wrong with the above method?
Additionally, I'd appreciate any hints on how you would track down this bug. My current approach is to add output to the console and selectively deactivating parts of the code.

I would suspect that in some cases the code you show poses a problem since InvokeRequired lies in case IsHandleCreated is false - it returns false even if you are not on the GUI thread.
For reference see http://msdn.microsoft.com/en-us/library/system.windows.forms.control.invokerequired.aspx .
The following code throws an exception instead of hanging... the fact that it "works as expected" when no breakpoint is hit might be a result of the debugger freezing all threads on hitting a breakpoint which in turn might lead to a different order of execution etc.
Altogether this means: you might have some "race condition" in your code where BeginInvokeIfRequired is called on a freshly created control before that control has a Handle. This can even be some 3rd-party code you use...
public static void BeginInvokeIfRequired(this Control control, Action action)
{
if (control.IsHandleCreated)
{
if (control.InvokeRequired)
{
control.BeginInvoke(action);
}
else
{
action.Invoke();
}
}
else {
// in this case InvokeRequired might lie !
throw new Exception ( "InvokeRequired is possibly wrong in this case" );
}
}

Debugging Nunit tests in Visual Studio C# Express 2010

I've followed this advice to get debugging working for NUnit tests.
http://www.blackwasp.co.uk/NUnitCSharpExpress.aspx
However, i have several tests that do Assert.Throws<...>, which causes the debugger to break when the exception i'm testing for occurs, when really i want it to break if an exception occurs outside of those calls.
How can i get the debugger to ignore exceptions caused from within these kinds of methods?
EDIT: I've event tried the below, which doesn't work!
[Test]
public void InstanciatingWithNullParameterThrowsException()
{
try
{
Assert.Throws<ArgumentNullException>(() => new CachedStreamingEnumerable<int>(null));
// This still throws and stops be being able to debug tests called after this one
}
catch
{
}
}

Here is what worked for me (although in Visual Studio Professional, not Express, but I guess that should not matter).
Bring up the "Exceptions" Dialog as suggested by Ninjapig.
Click on the Add... Button, to open the "New Exception" dialog.
Select "Common Language Runtime Exceptions" in the drop down box
In the Edit box enter "NUnit.Framework.AssertionException".
Click OK to close the "New Exception" dialog.
Back in the "Exceptions" dialog make sure that both checkboxes (Thrown and User-unhandled) are unchecked.
Now, the debugger should completely ignore a NUnit assertion failure (i.e. a thrown, caught or not, NUnit.Framework.AssertionException).
UPDATE: This will only prevent from breaking into the debugger, it cannot ignore the exception itself; i.e. it will not alter the actual program flow. Appart from changing or replacing or encapsulating the Assert-calls in try-catch blocks, I don't think there is anything that can achieve that (at least not automatically).

I'm uncertain if VS2010 Express has this option, but you can choose the exceptions to break on .
Go to the 'Debug' menu, then select 'Exceptions'
and from here you can select what exceptions to break on

I've ended up referencing nunit-gui-runner.dll and invoking it like
NUnit.Gui.AppEntry.Main(new string[] { Dll });
This brings up the NUnit gui. I can then run the specific test i'm interested in.

I had the same problem. Although your original approach (without the need for a try...catch block) works for most exception types, ArgumentNullException doesn't work. I fixed it like this:
[Test]
public void InstanciatingWithNullParameterThrowsException()
{
bool isArgumentNullExceptionThrown = false;
try
{
new CachedStreamingEnumerable<int>(null);
}
catch (ArgumentNullException)
{
isArgumentNullExceptionThrown = true;
}
Assert.That(isArgumentNullExceptionThrown);
}
It's not as elegant, but it does seem to work.