randmo crashes: EventType: clr20r3, system.nullreferenceexception

SharpCoderMP wrote:

i've been experiencing random crashes on some machines running my app.
the app never crashed in such way on my dev machine so i'm totally
unable to debug this.

the error page users get says nothing special:

EventType : clr20r3 P1 : app.exe P2 : 1.0.0.0 P3 : 24
P4 : app P5 : 1.0.0.0 P6 : 24 P7 : 11d P8 : 0

P9 : system.nullreferenceexception

any ideas where to start?

You need a stack trace. Make sure you have an unhandled exception
handler in AppDomain.UnhandledException, and log the exception info and
stack trace (Exception.StackTrace etc.).

i'm totally lost. i have absolutely no idea
what may cause this crashes.

IT's caused by a null reference, like the exception says. For example,
"((string) null).Length" will cause this crash, if there is no exception
handler.

-- Barry

--
http://barrkel.blogspot.com/

Hello, SharpCoderMP!
You wrote on Sun, 03 Sep 2006 15:52:34 +0200:

Sthe error page users get says nothing special:

SEventType : clr20r3 P1 : app.exe P2 : 1.0.0.0 P3 : 24
SP4 : app P5 : 1.0.0.0 P6 : 24 P7 : 11d P8 : 0

SP9 : system.nullreferenceexception

Have a look at
( http://blogs.msdn.com/tess/archive/2...27/584927.aspx )
this may help...

--
Regards, Vadym Stetsyak.
Blog: http://vadmyst.blogspot.com

Barry Kelly wrote:

You need a stack trace. Make sure you have an unhandled exception
handler in AppDomain.UnhandledException, and log the exception info and
stack trace (Exception.StackTrace etc.).

IT's caused by a null reference, like the exception says. For example,
"((string) null).Length" will cause this crash, if there is no exception
handler.

well, that is what i already know.

the problem is that this crash occurs randomly *but* the code path and
values involved during load time are always the same. the app is a
winform app and what's more strange - when the crash occurs code does
not even reach the constructor of a main form. no objects are
initialized before crash besides some strings and ints which values are
hard coded. to me it looks like something wrong is going on on the clr side.

>
-- Barry

Well, if I hear about random, intermittent and hard to reproduce erroes
where an object seems to be an impossible (or unexpected) value, my first
though is threading.

Are you perhaps doing anything funky involving threads? Perhaps the second
thread it setting / wiping the "null" variable (or expecting it to have a
value too early)? Threading issues tend to show up /sooner/ on multi-core
and/or hyper-threaded chips (but it is still bug-capable on a basic CPU).
They can also show differently depending on CPU load, so all the ticks are
in the boxes...

I would add a global exception handler, both around my exsiting Main code
and to Application.ThreadException, and look at the stack trace / message
etc. Note that 2.0 (2005) will baulk more that 1.1 (2003) when accessing
form controls on the wrong thread (which is good), but it won't
automatically catch custom user code.

Marc

threads... yeah that was my thought also :/
during startup my app does almost nothing with threads... except
displaying a splash screen on a separate thread... but the splash screen
displays correctly. and the code behind the splash screen does
absolutely nothing beside providing output to the user that comes from
the main thread. this is achieved through calls to some static methods
of the splash screen class.
in general splash screen code is so simple (about 100lines)... i have no
idea what can crash there. it's based on some quite good example from
codeproject.com (don't have the link right now).
there is no real cross threaded action beside passing strings from main
thread to the one that splash screen runs on (the splash thread is STA).
but crash occurs even before any data is passed to the splash screen
thread - at least that is what it looks like :/

Marc Gravell wrote:

Well, if I hear about random, intermittent and hard to reproduce erroes
where an object seems to be an impossible (or unexpected) value, my first
though is threading.

Are you perhaps doing anything funky involving threads? Perhaps the second
thread it setting / wiping the "null" variable (or expecting it to have a
value too early)? Threading issues tend to show up /sooner/ on multi-core
and/or hyper-threaded chips (but it is still bug-capable on a basic CPU).
They can also show differently depending on CPU load, so all the ticks are
in the boxes...

I would add a global exception handler, both around my exsiting Main code
and to Application.ThreadException, and look at the stack trace / message
etc. Note that 2.0 (2005) will baulk more that 1.1 (2003) when accessing
form controls on the wrong thread (which is good), but it won't
automatically catch custom user code.

Marc

STA doesn't really (AFAIK) affect pure CLR code (which is fully threaded);
as I understand it, it only impacts external calls across OLE/COM etc. I
might be wrong ;-p

If I was a gambling man, I'd look at the code that initiates the splash
screen, or any events that are fired between them - but without postable
code it is hard to imagine exactly where the issue might be.

Ooh - one just popped in - perhaps the splash is trying to trigger an event
that the primary thread hasn't quite (on some CPUs) subscribed to yet, and
is doing:

SomeEvent(this, EventArgs.Empty);

instead of:

EventHandler handler = SomeEvent;
if(handler!=null) handler(this, EventArgs.Empty);

Just a thought.

Marc

ok. i've probably pinned it down.
thanks for your clues about threading and AppDomain (the AppDomain thing
came out to be very useful)

now the reason of all my stress:
first: users were absolutely sure that crash occurs just *after* splash
is shown... wrong, wrong, wrong! app crashed just *before* splash was
shown. being assured by the users that crash occurs after splash screen
is shown i was looking for crash reasons on the main thread that brings
to life my main form.
second: dump from AppDomain revealed that indeed we were dealing with
splash screen / threading related problem.

now came the easy part :) these two clues led me to the source of my
problems: main thread was trying to access splash screen whereas the
thread that the splash supposed to run on was not yet started. so the
static splash screen object was not yet created hence the
NullObjectReferenceException.

temporary solution was to return from static splash screen method if the
static splash screen was still a null.

the 'real' solution would be to block main thread (or queue splash
screen methods invoking) until splash is started. I'd probably choose
first solution - now i have to figure out how to do it the 'safe way'.

but there is still one thing - why this crashes were so random? it seems
that the crash was not related to the processor load. the only pattern
that came out was that app crashed almost always when it was started for
the first time after boot. it's like jitting taking too long or
something like that but related to the CLR? of course not all machines
reported such crashes.

anyway - thanks again Marc.
Marc Gravell wrote:

STA doesn't really (AFAIK) affect pure CLR code (which is fully threaded);
as I understand it, it only impacts external calls across OLE/COM etc. I
might be wrong ;-p

If I was a gambling man, I'd look at the code that initiates the splash
screen, or any events that are fired between them - but without postable
code it is hard to imagine exactly where the issue might be.

Ooh - one just popped in - perhaps the splash is trying to trigger an event
that the primary thread hasn't quite (on some CPUs) subscribed to yet, and
is doing:

SomeEvent(this, EventArgs.Empty);

instead of:

EventHandler handler = SomeEvent;
if(handler!=null) handler(this, EventArgs.Empty);

Just a thought.

Marc

No problem - glad you got it sorted; and if you wanted to do it the "proper"
way, you could share a ManualResetEvent; call .WaitOne() on it after
starting the splash-code, and and .Set() it on the .Load event of the
splash.

I have adapted an example from last week (to now include waiting for load),
in case it helps (note: it is only the two smaller code blocks that should
need much tweaking):

using System;
using System.Windows.Forms;
using System.Threading;

class MySplashForm : Form {

public MySplashForm() {
Thread.Sleep(3000);// I take a while to construct ;-p
Text = "I'm a splash form";
FormBorderStyle = FormBorderStyle.FixedDialog;
ShowInTaskbar = MinimizeBox = MaximizeBox = false;
}
}
class Program {
static void Main() {
using (Splash<MySplashFormloader = new Splash<MySplashForm>()) {
loader.WaitForLoad();
// can also look at loader.Form.whatever...
Thread.Sleep(5000); // do something while the splash is up
}
MessageBox.Show("That do?");
}
}
class Splash<T: IDisposable where T : Form, new() {
T _form;
bool disposed = false;
readonly ManualResetEvent _loaded = new ManualResetEvent(false);
private void CheckDisposed() {
if (disposed) throw new ObjectDisposedException(GetType().Name);
}
public T Form {
get {
CheckDisposed();
return _form;
}
}
public void WaitForLoad() {
CheckDisposed();
_loaded.WaitOne();
}
public bool WaitForLoad(TimeSpan timespan, bool exitContext) {
CheckDisposed();
return _loaded.WaitOne(timespan, exitContext);
}
public Splash() {
Thread thread = new Thread(Show);
thread.IsBackground = true;
thread.Start();
}
private void Show() {
_form = new T();
using (T form = _form) {
form.Load += delegate {
_loaded.Set();
form.Activate();
};
form.ShowDialog();
} // to ensure disposed on exit
}
private void Close() {
try { _form.Close(); } catch { } // swallow
}
public void Dispose() {
if (_form != null) {
disposed = true; // set early
try { _form.Invoke((MethodInvoker)this.Close); } catch { } //
swallow
_form = null;
}
}
}

hmmm, not exactly what i need but WaitOne() solution seems adaptable for
me :)

Marc Gravell wrote:

No problem - glad you got it sorted; and if you wanted to do it the "proper"
way, you could share a ManualResetEvent; call .WaitOne() on it after
starting the splash-code, and and .Set() it on the .Load event of the
splash.

I have adapted an example from last week (to now include waiting for load),
in case it helps (note: it is only the two smaller code blocks that should
need much tweaking):

using System;
using System.Windows.Forms;
using System.Threading;

class MySplashForm : Form {

public MySplashForm() {
Thread.Sleep(3000);// I take a while to construct ;-p
Text = "I'm a splash form";
FormBorderStyle = FormBorderStyle.FixedDialog;
ShowInTaskbar = MinimizeBox = MaximizeBox = false;
}
}
class Program {
static void Main() {
using (Splash<MySplashFormloader = new Splash<MySplashForm>()) {
loader.WaitForLoad();
// can also look at loader.Form.whatever...
Thread.Sleep(5000); // do something while the splash is up
}
MessageBox.Show("That do?");
}
}
class Splash<T: IDisposable where T : Form, new() {
T _form;
bool disposed = false;
readonly ManualResetEvent _loaded = new ManualResetEvent(false);
private void CheckDisposed() {
if (disposed) throw new ObjectDisposedException(GetType().Name);
}
public T Form {
get {
CheckDisposed();
return _form;
}
}
public void WaitForLoad() {
CheckDisposed();
_loaded.WaitOne();
}
public bool WaitForLoad(TimeSpan timespan, bool exitContext) {
CheckDisposed();
return _loaded.WaitOne(timespan, exitContext);
}
public Splash() {
Thread thread = new Thread(Show);
thread.IsBackground = true;
thread.Start();
}
private void Show() {
_form = new T();
using (T form = _form) {
form.Load += delegate {
_loaded.Set();
form.Activate();
};
form.ShowDialog();
} // to ensure disposed on exit
}
private void Close() {
try { _form.Close(); } catch { } // swallow
}
public void Dispose() {
if (_form != null) {
disposed = true; // set early
try { _form.Invoke((MethodInvoker)this.Close); } catch { } //
swallow
_form = null;
}
}
}