Crash on WM 5.0 after turn off/on

[Hilton]

Hi,

I have a strange one. Application runs just fine. If I turn the PDA off,
then back on, then sometime in the future I get the following exception when
showing a Dialog or switching forms etc. I cannot repro this on 2003 SE and
it only happens after turning the PDA off for a while. I cannot repro this
by minimizing the app - I thought it might be related to the GC. I'm pretty
sure that any threads I may have do not do any UI.

Any suggestions how to debug this?

ExceptionCode: 0xc0000005
ExceptionAddress:0x01def4ac
Reading: 0x49e52518

Thanks,

Hilton

 

[Guest]

As a guess, is the app itself running from a storage card, or using a
database on a storage card?

-Chris

 

[Hilton]

Correct! OK, this sounds good. More info? URL?

Thanks Chris, and thanks for your tremendous contributions on these NGs.

Hilton

 

[Paul G. Tobey [eMVP]]

Well, don't run it from the storage card ;-) There's nothing *you* can do
about it, otherwise.

Paul T.

 

[Hilton]

Well, don't run it from the storage card ;-) There's nothing *you* can do
about it, otherwise.

FYI: Since reading Chris' post, I tried the EXE in main memory and the
databases on the card (X51) - I haven't crashed it yet. I tried
EXE+databases on the card on 2003 SE (on an X30) and no crashes yet.

So, it might be Axim-related, WM 5.0-related, Compact Framework-related etc,
but at least I can tell customers to install into main memory and put their
databases on a card.

HOWEVER, what's the deal here? Is this a WM 5.0 problem? Is this a CF
problem? Does anyone know the specifics of this problem. I'm absolutely
amazed (stunned) that WM 5.0 cannot run EXEs from a card!!!

Thanks,

Hilton

 

[Hilton]

Hi,

Another followup:

CF 1.0 and CF 2.0 produce the same results.

Now usually the app dies with come exception 0xc0000008 (I think). However,
occasionally it dies with the following Error Reporting text (not sure if
anyone can make sense of this):

EvntType: WinCE501bExceptio (no typo; i.e. no "n")
<app specific stuff here>
ModName: coredll.dll
Modver: 5.1.0.0
ModStamp: acd9c6b2
Offset: 00052270

Info Flags: 0x00000008
Current Process: 0x8F582236
Faulting Thread: 0x8EFFA566
Owner Process: 0x8F582236
Code: 0xC0000005
Flags: 0x00000000
Record: 0x00000000
Address: 0x03FB2270
Parameters: 2
Param [0]: 0x00000000
Param [1]: 0x47A47388

Hilton

 

[Guest]

I posted the reason for this somewhere - thought it waqs my blog, but I
can't find it now. The short of it is that when the device shuts off, the
card/mountable storage is unmounted, making any file handles invalid when
you start back up. For an app, that means when it tried to page in data
again, it blows up (fixed by not running from external storage). For data
it means closing and reopening data files on wake.

-Chris

 

[Hilton]

Chris,

Thanks for all the info. One more question: Does this have anything to do
with, or is it made worse by, the fact that the CF 'JITs' and therefore
reads in the EXE piece by piece? Would an EXE written in C experience the
same problem?

How about this logic for the Compact Framework:

filename = "some EXE or DLL";
if (filename.IsOncard)
{
Copy (filename to Main Memory);
filename = main memory location;
}
run EXE or DLL (filename)

i.e. copy EXE/DLL to main memory before running it?

Another thought, the CF could compile the entire EXE into main memory and
then not have to access the card again.

Doesn't this all make a mockery of 'instant on'? i.e. when the PPC gets
turned on, every running app needs to re-initialize their file/database
access (if on a card) etc etc...

OK, absolutely final one: Why do Pocket PCs even give the option of
installing the app to a card if it doesn't work?

Thanks,

Hilton [Still absolutely amazed that the Pocket PC is so broken handling
this, and I love the Pocket PC]

 

[Guest]

Thanks for all the info. One more question: Does this have anything to do

with, or is it made worse by, the fact that the CF 'JITs' and therefore
reads in the EXE piece by piece? Would an EXE written in C experience the
same problem?

Has nothing to do with managed or unmanaged. CE pages in the data it needs
from the store, so when you end up calling something that it needs, it
pukes. A native app would do the same.

How about this logic for the Compact Framework:

filename = "some EXE or DLL";
if (filename.IsOncard)
{
Copy (filename to Main Memory);
filename = main memory location;
}
run EXE or DLL (filename)

i.e. copy EXE/DLL to main memory before running it?

Yep, that's the way to do it.

Another thought, the CF could compile the entire EXE into main memory and
then not have to access the card again.

Can't be done.

Doesn't this all make a mockery of 'instant on'? i.e. when the PPC gets
turned on, every running app needs to re-initialize their file/database
access (if on a card) etc etc...

Not really - instant on works fine. The issue is that the media controller
is shut off when you suspend to save power. When you wake it's re-powered.
The OS doesn't know that it was the old volume, it just sees it as a new
volume being mounted. The device OEM has the ability to deal with that, but
it's a lot more work than just letting it remount, which is why it's pretty
common to see it that way.

OK, absolutely final one: Why do Pocket PCs even give the option of
installing the app to a card if it doesn't work?

Because it's an implementation issue from the OEM. CE itself has no
limitation here. If the OEM does the work to maintain handles across
suspend/resume it works. If they don't it doesn't. Microsoft can't know
what they'll opt to do.

-Chris

 

[Hilton]

Chris,

Has nothing to do with managed or unmanaged. CE pages in the data it
needs from the store, so when you end up calling something that it needs,
it pukes. A native app would do the same.

Thanks for the post. On the Microsoft forums, Ilya Tumanov [MS] said: "Apps
are not paged and NETCF loads modules into memory as whole keeping them in
memory at all times. NETCF can pitch JITed code, but not managed assembly."

Do you know of a detailed enough doc that would tell us if EXEs are paged or
not?

Thanks,

Hilton

 

[Guest]

Interesting. I'd want to discuss it with Ilya then, as I've seen the exact
same behavior you see, and the only thing that makes any sense is paging.
Did he offer some alternative explanation for the behavior you're seeing?

-Chris

Chris,

Has nothing to do with managed or unmanaged. CE pages in the data it
needs from the store, so when you end up calling something that it needs,
it pukes. A native app would do the same.

Thanks for the post. On the Microsoft forums, Ilya Tumanov [MS] said:
"Apps are not paged and NETCF loads modules into memory as whole keeping
them in memory at all times. NETCF can pitch JITed code, but not managed
assembly."

Do you know of a detailed enough doc that would tell us if EXEs are paged
or not?

Thanks,

Hilton

 

[Hilton]

Chris,

Here is the foum thread with more info about the crash and device/OSs I've
tried:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=553374&SiteID=1

Thanks,

Hilton

Interesting. I'd want to discuss it with Ilya then, as I've seen the
exact same behavior you see, and the only thing that makes any sense is
paging. Did he offer some alternative explanation for the behavior you're
seeing?

-Chris

Chris,

Has nothing to do with managed or unmanaged. CE pages in the data it
needs from the store, so when you end up calling something that it
needs, it pukes. A native app would do the same.

Thanks for the post. On the Microsoft forums, Ilya Tumanov [MS] said:
"Apps are not paged and NETCF loads modules into memory as whole keeping
them in memory at all times. NETCF can pitch JITed code, but not managed
assembly."

Do you know of a detailed enough doc that would tell us if EXEs are paged
or not?

Thanks,

Hilton

 

[Hilton]

Chris,

Ilya suggested that I run the app from the card, then remove the card
(without pwr/off/on). Here is my reply:

---
Hi,

With the app in its own directory (i.e. no data files), I ran it, after it
had got to the main screen, I removed the SD card and then pretty much
anything I did caused the crash - even just tapping on the main menu -
pretty much anything.

So, my conclusion, is that WM 5.0 is paging in the app which is why the pwr
off/on problem occurs. You agree?

FYI: I tried the exact same test with the X30 running 2003 SE and this time
I saw the crash (first time on 2003SE).

Thanks,

Hilton

 

[Hilton]

Chris,

I just created a repro case; no PInvokes etc. Works fine in memory, on a
card, does when I remove the card; also crashes if I run it, then turn
off/on. My post to the forum and my email to Ilya appear below. Let me
know if you would like to see the code.

Bottom line , 100% reproducable pure simple C# example.

My email address is: [first name]goldstein[at]mindspring.com

Hilton

-----
Ilya,

I think the small test application won't page because it is small. I
created a test case that simply does:

Form form00001 = new Form00001(); form00001.Show(); form00001.Dispose();
:
Form form00099 = new Form00099(); form00099.Show(); form00099.Dispose();


i.e. 100 separate Form classes. Runs in main memory fine, runs fine on
card, crashes when I remove card. I will email the EXE to you. If you want
the source let me know. It is all pure C#, no other code that what VS 2003
generated to create the blank app (New, Project) and the lines you see
above.

Thanks,

Hilton
-----
Ilya,

This is an app that crashes as per our forum discussion. Run the app from a
card. Tap on test (main menu), then tap on Forms. Runs fine. Now remove
card. Run the app again. It runs fine! Why? Because all the 100 classes
have been paged in.

Now kill the app (Settings, Memory, Running Programs, Stop).

Run the app again, this time remove the card before tapping on Test|Forms -
it crashes because it cannot page in the forms.

Note about the ZIP:
1. I removed the PDB files to make the zip smaller
2. I renamed TestPaging.exe in the bin\debug directory to TestPaging.xyz -
simpy rename to TestPaging.exe or recompile

Hilton