native exception inside mscoree1_0.dll. Root cause?!

  • Thread starter Thread starter Patrick Berny
  • Start date Start date
P

Patrick Berny

Hi all:

I've been going insane over this issue. I'm intermittently getting a
native exception inside mscoree1_0.dll (usually at address x01676854,
exception code 0xc0000005, see below for modules loaded in process) and
have no clue what could be causing this. I'm using SP3 of .NetCF on
Windows Mobile 2003 SE.

It happens quite infrequently (hard to reproduce), but seems to be
ocurring a bit more often after coming out of standby. Could this be due
to GC doing some cleanup at that point?

I'm running out of ideas what could be causing this, since pretty much
all of the app is in managed code. There's little p/invoke happening,
but that part I'm pretty confident is stable and good, especially since
it can run for days without having the issue.

Since I cannot trap the native exceptions inside the C#, I'm in a bit of
bad shape.

Any help/ideas on possible cause or how to go about finding it are very
much appreciated (e.g. how could I get the call stack).

Patrick

Here's the module dump:

Module mscoree1_0.dll at address 0x1640000, size 0x8B000
Module coredll.dll at address 0x1F60000, size 0x85000
Module toolhelp.dll at address 0x21A0000, size 0x5000
Module ossvcs.dll at address 0x22F0000, size 0x2C000
Module netcfagl1_0.dll at address 0x2320000, size 0x28000
Module mscoree.dll at address 0x2350000, size 0x8000
Module oleaut32.dll at address 0x2360000, size 0x30000
Module ole32.dll at address 0x2390000, size 0x2F000
Module shutil.dll at address 0x27B0000, size 0x8000
Module aygshell.dll at address 0x27E0000, size 0x2E000
Module commctrl.dll at address 0x2840000, size 0x5C000
Module cellcore.dll at address 0x2980000, size 0x8000
Module wininet.dll at address 0x2D40000, size 0x78000
Module shlwapi.dll at address 0x2DD0000, size 0x13000
Module ssllsp.dll at address 0x3020000, size 0xA000
Module wspm.dll at address 0x3040000, size 0x6000
Module ws2.dll at address 0x3060000, size 0xC000
Module winsock.dll at address 0x3070000, size 0x5000
Module iphlpapi.dll at address 0x3080000, size 0x10000
Module shlwapi.dll.0409.mui at address 0x7FEC0000, size 0x2000
Module wininet.dll.0409.mui at address 0x7FED0000, size 0x9000
Module tshres.96.dll at address 0x7FF30000, size 0x4000
Module shellres.dll at address 0x7FF40000, size 0x56000
Module tshres.dll at address 0x7FFA0000, size 0x14000
Module coredll.dll.0409.mui at address 0x7FFE0000, size 0x17000
 
Most common case would be to allocate some managed memory and pass it to
the native code without pinning it first.
Memory would be gone on GC, native code would write to unallocated memory
causing an exception.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
 
Hello Ilya:

thanks for the tip. Unfortunately we're not passing pointers to managed
memory to be used in C code for longer than the current function call,
in which case I understand the runtime pins it for us automatically,
right? That is, unless CeSetUserNotificationEx would cache the pointer,
but I really doubt that's the case.

Patrick

(e-mail address removed) ("Ilya Tumanov [MS]") wrote in
 
I also doubt CeSetUserNotificationEx cashes anything. However, it sure
takes a structure like this:

typedef struct UserNotificationTrigger {
DWORD dwSize;
DWORD dwType;
DWORD dwEvent;
WCHAR *lpszApplication;
WCHAR *lpszArguments;
SYSTEMTIME stStartTime;
SYSTEMTIME stEndTime;
} CE_NOTIFICATION_TRIGGER, *PCE_NOTIFICATION_TRIGGER;


Note it has couple pointers in it which is not supported by CF directly.
That means you have to allocate native or managed memory for the string,
get a pointer to it and assign it to IntPrt (or equivalent) inside this
structure.
That memory is not pinned for you even for the duration of the call. If you
don't pin it manually (or allocate native memory instead), you're in for a
nasty surprise.
Consider checking all P/Invokes for something like this.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
Subject: RE: native exception inside mscoree1_0.dll. Root cause?!
From: Patrick Berny <[email protected]>
References: <[email protected]>
Click to expand...
Message-ID: <[email protected]>
User-Agent: Xnews/5.04.25
Newsgroups: microsoft.public.dotnet.framework.compactframework
Date: Tue, 15 Mar 2005 11:36:57 -0800
NNTP-Posting-Host: gateway.globallocate.com 216.15.9.34
Lines: 1
Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP1
2.phx.gbl
Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.dotnet.framework.compactframework:73286
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

Hello Ilya:

thanks for the tip. Unfortunately we're not passing pointers to managed
memory to be used in C code for longer than the current function call,
in which case I understand the runtime pins it for us automatically,
right? That is, unless CeSetUserNotificationEx would cache the pointer,
but I really doubt that's the case.

Patrick

(e-mail address removed) ("Ilya Tumanov [MS]") wrote in
Most common case would be to allocate some managed memory and pass it
to the native code without pinning it first. Memory would be gone on
GC, native code would write to unallocated memory causing an
exception.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no
rights.

--------------------
Click to expand...
Click to expand...
 
Hi Ilya:

thanks so much for your valuable input. I've checked the P/Invoke code
again and I don't think the problem comes from there. The
lpszApplication and lpszArguments pointers are allocated in unmanaged
memory (using LocalAlloc), so they should be fine.

Best regards,
Patrick

(e-mail address removed) ("Ilya Tumanov [MS]") wrote in
I also doubt CeSetUserNotificationEx cashes anything. However, it sure
takes a structure like this:

typedef struct UserNotificationTrigger {
DWORD dwSize;
DWORD dwType;
DWORD dwEvent;
WCHAR *lpszApplication;
WCHAR *lpszArguments;
SYSTEMTIME stStartTime;
SYSTEMTIME stEndTime;
} CE_NOTIFICATION_TRIGGER, *PCE_NOTIFICATION_TRIGGER;


Note it has couple pointers in it which is not supported by CF
directly. That means you have to allocate native or managed memory for
the string, get a pointer to it and assign it to IntPrt (or
equivalent) inside this structure.
That memory is not pinned for you even for the duration of the call.
If you don't pin it manually (or allocate native memory instead),
you're in for a nasty surprise.
Consider checking all P/Invokes for something like this.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no
rights.

--------------------
Subject: RE: native exception inside mscoree1_0.dll. Root cause?!
From: Patrick Berny <[email protected]>
References: <[email protected]>
Click to expand...
Message-ID: <[email protected]>
User-Agent: Xnews/5.04.25
Newsgroups: microsoft.public.dotnet.framework.compactframework
Date: Tue, 15 Mar 2005 11:36:57 -0800
NNTP-Posting-Host: gateway.globallocate.com 216.15.9.34
Lines: 1
Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!
Click to expand...
TK2MSF
TNGP1 2.phx.gbl
Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.dotnet.framework.compactframework:73286
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

Hello Ilya:

thanks for the tip. Unfortunately we're not passing pointers to
managed memory to be used in C code for longer than the current
function call, in which case I understand the runtime pins it for us
automatically, right? That is, unless CeSetUserNotificationEx would
cache the pointer, but I really doubt that's the case.

Patrick

(e-mail address removed) ("Ilya Tumanov [MS]") wrote in
Most common case would be to allocate some managed memory and pass
it to the native code without pinning it first. Memory would be
gone on GC, native code would write to unallocated memory causing
an exception.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no
rights.

--------------------
Click to expand...
Click to expand...
Click to expand...
 
Well, it's always possible CF has some bug we don't know about.

However, P/Invoke code (as you have more of them) is still under suspicion.
Can you remove some/all P/Invokes and see if it fails?

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
Subject: RE: native exception inside mscoree1_0.dll. Root cause?!
From: Patrick Berny <[email protected]>
References: <[email protected]>
Click to expand...
<[email protected]>
Message-ID: <[email protected]>
User-Agent: Xnews/5.04.25
Newsgroups: microsoft.public.dotnet.framework.compactframework
Date: Tue, 15 Mar 2005 15:04:06 -0800
NNTP-Posting-Host: gateway.globallocate.com 216.15.9.34
Lines: 1
Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP1
2.phx.gbl
Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.dotnet.framework.compactframework:73305
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

Hi Ilya:

thanks so much for your valuable input. I've checked the P/Invoke code
again and I don't think the problem comes from there. The
lpszApplication and lpszArguments pointers are allocated in unmanaged
memory (using LocalAlloc), so they should be fine.

Best regards,
Patrick

(e-mail address removed) ("Ilya Tumanov [MS]") wrote in
I also doubt CeSetUserNotificationEx cashes anything. However, it sure
takes a structure like this:

typedef struct UserNotificationTrigger {
DWORD dwSize;
DWORD dwType;
DWORD dwEvent;
WCHAR *lpszApplication;
WCHAR *lpszArguments;
SYSTEMTIME stStartTime;
SYSTEMTIME stEndTime;
} CE_NOTIFICATION_TRIGGER, *PCE_NOTIFICATION_TRIGGER;


Note it has couple pointers in it which is not supported by CF
directly. That means you have to allocate native or managed memory for
the string, get a pointer to it and assign it to IntPrt (or
equivalent) inside this structure.
That memory is not pinned for you even for the duration of the call.
If you don't pin it manually (or allocate native memory instead),
you're in for a nasty surprise.
Consider checking all P/Invokes for something like this.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no
rights.

--------------------
Subject: RE: native exception inside mscoree1_0.dll. Root cause?!
From: Patrick Berny <[email protected]>
References: <[email protected]>
Click to expand...
Message-ID: <[email protected]>
User-Agent: Xnews/5.04.25
Newsgroups: microsoft.public.dotnet.framework.compactframework
Date: Tue, 15 Mar 2005 11:36:57 -0800
NNTP-Posting-Host: gateway.globallocate.com 216.15.9.34
Lines: 1
Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!
Click to expand...
TK2MSF
TNGP1 2.phx.gbl
Xref: TK2MSFTNGXA02.phx.gbl microsoft.public.dotnet.framework.compactframework:73286
X-Tomcat-NG: microsoft.public.dotnet.framework.compactframework

Hello Ilya:

thanks for the tip. Unfortunately we're not passing pointers to
managed memory to be used in C code for longer than the current
function call, in which case I understand the runtime pins it for us
automatically, right? That is, unless CeSetUserNotificationEx would
cache the pointer, but I really doubt that's the case.

Patrick

(e-mail address removed) ("Ilya Tumanov [MS]") wrote in

Most common case would be to allocate some managed memory and pass
it to the native code without pinning it first. Memory would be
gone on GC, native code would write to unallocated memory causing
an exception.

Best regards,

Ilya

This posting is provided "AS IS" with no warranties, and confers no
rights.
Click to expand...
Click to expand...
Click to expand...
 
Hi Ilya:

I can try to remove all self-created P/Invokes and see what happens, but
it will probably make it impossible to reproduce the issue by virtue
that I rely on the CeSetUserNotificationEx to be woken up after some
time in order to do anything at all. I can manually invoke the
functionality through a tray icon (that code is in C++), but I can
normally go for various days before I see the crash (with a wakeup timer
of 15 minutes).

Do you think the following could be a reasonable explanation why I'm
seeing my crash; supposedly the O/S image on the device contains .NetCF
SP3 (look at my module dump in the first posting).

"The XIPKERNEL region must be the "first" in terms of address order or
else the OS reservation code malfunctions and does not reserve enough
space for all regions, in this case, the mscoreee1_0 is hanging off the
end.
Re-sorting the regions in slots 0 and 1 solve the problem."

My interpretation is that the mscoree1_0 is supposed to be in XIP, so
the base address should be above 0x200000, but it isn't according to my
dump of toolhelp info.

Best regards,
Patrick

(e-mail address removed) ("Ilya Tumanov [MS]") wrote in
 
Back
Top