Develop Reference

Detecting when a DLL has raised an exception

OK, so I have the C# DLL method:
public void DeletePublisher(string strName)
{
try
{
if (_PublisherData.PublisherDictionary.ContainsKey(strName))
_PublisherData.PublisherDictionary.Remove(strName);
}
catch (Exception ex)
{
SimpleLog.Log(ex);
}
}
It works fine. If there is a exception it is detected and added to the log.
At the moment, the above is called via MFC in my C++ project using a wrapper:
bool CMSATools::DeletePublisher(CString strPublisher)
{
bool bDeleted = false;
if (m_pInterface != nullptr)
{
CComBSTR bstrPublisher = strPublisher.AllocSysString();
throw_if_fail(m_pInterface->DeletePublisher(bstrPublisher));
bDeleted = true;
}
return bDeleted;
}
They both work fine. The issue is that fact that the CPP method currently has no knowledge of the C# method having failed. Now, in this particular instance I know I could change the signature of the DLL method to return false for a exception failure occurring and examine that return value in the CPP file.
But, in other instances I am already using the return value and thus, it would seem for consistency to me, that I pass in a bool bExceptionRaised parameter instead to my methods in the DLL.
That way, I can test that value when the method seemed to complete and if it is false act accordingly.
At the moment my application doesn't realise that an exception occurred and that is confusion.
Can I assume that either of these methodologies are the simplest approach to what I am trying to detect?
Update
Based on the answer provided I have tried to follow this tutorial and I am getting confused. I have tried to follow it and I can't create a CLR DLL and build it that is a bridge to my C# DLL file.
Whilst I appreciate the answer I feel like it is breaking up everything I have worked on since the C# DLL already handles and logs it's exceptions. Whilst I would like to learn how to build this bridge for the future, I still think perhaps at the point in time just changing my signatures is sufficient. Either way, my attempt a basic build of a bridge is failing.

Use a C++/CLI wrapper for the access of the managed component.
With C++/CLI you can directly use the C# component can catch the managed exception and you can throw a native exception or even return true or false... whatever you want.
void DoManagedStuff(SOMEDATA somedata)
{
try
{
auto sm = ConvertToSomeDataToManaged(somedata);
CallManagedCode(sm);
}
catch (Exception^ e)
{
throw CMyNativeException();
}
}

Problems exiting C# program that uses R.Net

I have a small program in C# that loads the R.Net library to outsource some calculations that I can't do in c#, namely the Twitter anomaly detection library. Unfortunately, when the code finishes the console window it runs in hangs. If I run it in debug, code execution seems to be error free, so I suspect it's something to do with cleanup of the REngine as I (eventually) get an error as per this image.
After which I'll get another pop up from VS stating "Debugging is stopped but is not yet complete, either force it to stop by pressing this button or continue to wait".
Code is approximately as follows:
class SHESD_Test
{
private static REngine engine;
internal SHESD_Test(IEnumerable<Double> d)
{
try
{
if(engine==null)
{
engine = REngine.GetInstance();
engine.Initialize();
engine.Evaluate("library(AnomalyDetection)"); //Loads Twitter library
}
var dInR = engine.CreateNumericVector(d.toArray());
engine.SetSymbol("data", dInR);
var outVar = engine.Evaluate("outVar <- AnomalyDetectionVec(data, max_anoms=0.02, direction='both', plot=FALSE, period=96)");
/* Some other stuff that grabs data out of outVar in R and stores in member variables */
}
catch (Exception e)
{ /* Log error */ }
}
//Called from elsewhere once everything is complete, but behaviour is the same if I don't call it
internal static void cleanup()
{
engine.ForceGarbageCollection();
engine.Dispose();
engine == null;
}
}
Googling the error code, it looks like a timeout has expired, but for the life of me I can't figure out why.
The code itself executes fine, it's only in the exit from main(), and not the bit where the REngine falls out of scope, so perhaps in garbage collection things are going awry?

Digging further, the root cause is in the library function generating a plot window in it's return value, even when told not to. Their code is:
# Lastly, return anoms and optionally the plot if requested by the user
if(plot){
return (list(anoms = anoms, plot = xgraph))
} else {
return (list(anoms = anoms, ***plot = plot.new()***)) # <-Looky here!
}
Adding to my code the following line when I'm done with the engine:
engine.Evaluate("graphics.off()");
closes the strange empty window, which doesn't seem to be able to be closed by either the ForceGarbageCollection or Dispose methods - probably leaving things hanging about waiting for something that will never happen, and thus triggering this timeout exception window.

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.

AccessViolationException in debugger with only managed code and WCF service

This application has a WCF web service that is called by a WinForms app. The WinForms app has a class WCFCache to manage data from the service. There is a section like this in that class to manage an optional custom configuration section that a subset of the machines have:
private bool? m_HasCustomConfiguration = null;
public bool HasCustomConfiguration
{
get
{
if (m_HasCustomConfiguration == null)
m_HasCustomConfiguration = (CustomConfiguration != null);
return (bool)m_HasCustomConfiguration;
}
}
private WCFService.CustomConfiguration m_CustomConfiguration = null;
public WCFService.CustomConfiguration CustomConfiguration
{
get
{
if (m_CustomConfiguration == null)
{
if (m_HasCustomConfiguration.HasValue
&& !m_HasCustomConfiguration.Value)
return null;
try
{
using (WCFService.WCFServiceClient wcf = new WCFService.WCFServiceClient())
{
m_CustomConfiguration =
wcf.GetCustomConfiguration(Machine.ProcessID);
// Above method returns null if no record exists.
m_HasCustomConfiguration = (m_CustomConfiguration != null);
}
} catch (Exception e) {
// Error logging & re-throw
}
}
return m_CustomConfiguration;
}
}
When I step through the debugger in code that calls either of the above properties like this:
if (!Program.WCFCache.HasCustomConfiguration)
return new List<CustomComponents>();
...it throws the following exception:
System.AccessViolationException was unhandled
Message="Attempted to read or write protected memory. This is often an indication that other memory is corrupt."
Source="System.Windows.Forms"
...
When I step onto the line containing the reference, there is a long pause, followed by a VS popup with the exception.
The exception doesn't appear when I just put a breakpoint after the above code has executed. It doesn't even appear when I put a breakpoint inside the accessors of the properties. It only occurs when I step onto a line with one of those properties from the outside. (So there is a workaround, but it can be a pain.)
Why is this happening? Can I stop it?
Edit: The whole application was written in the last year in 3.5 C#/.NET with WCF communicating between components; meaning, we don't have legacy unmanaged DLLs. Just two unmanaged calls: one to advapi32.dll when the WinForms app is loading, in the username detection procedure. The issue I'm having happens only in this one place in the code, in a place that is about as unrelated to the login section as you can get. The other is to kernel32.dll, in a GC force-flush long after anything is done with the results from calls like the one above.

Are you using any P/Invoke or other such native code? Odds are, that's where you should start looking.
This exception is a symptom of a larger problem, namely memory corruption (that what the exception says, after all). If this was a native application, you'd get a crash.
So, look at any native calls, make sure they're operating correctly, maybe run them under a debugger to try and trap the error closer to home.
Sorry, can't really give better advice given the circumstances.

I eventually found that others have encountered this situation and that it is likely a Visual Studio bug. I was using VS 2008 when the problem occurred.

Something wrong with this gtk# class for a window?

Learning C#, I feel so guilty for loving it. I'm a microsoft hater. Anyways I'm trying out gtk# and just trying out some simple stuff. I've made a class for the main window and MonoDevelop is complaining about this code, which I swear was just fine a second ago.
public class mwin
{
protected Window win = new Window("test program--");
public mwin()
{
//Configure the parts
win.SetDefaultSize(300,500);
}
public void showWin()
{
win.ShowAll();
}
}
win.SetDefaultSize(300,500);
}--<(here it says "} expected")
But obviously I have a closing brace! Am I missing something?
[edit]
here's whole code. The color stuff was some stuff I was playing around with to color the window, but I didn't finish because the error started. I'm sure it's not the color stuff because it still has an error when I comment them out. http://codepaste.net/b2mwys

You have put your call to "win.SetDefaultSize(300,500);" outside of a method block. The compiler is expecting a closing brace.