57 replies to this topic

[eduuuuu]

Ive tried kuanchai hybrid ROM (lastest 2-Aug)... and the problem was still there

I've changed to Ryrzy ROM (hybrid 23016/21928 DXID1) - and the problems seems to be gone!

I have installed all the applications that I thought would cause this problem.. and nothing bad happened yet. (s2u2, s2p, wktask, pocketalarm, sktools, Mobile Shell3, MS3Config)

There is one thing I haven't done: (optimized to performance inside sktools) -> if someone experience the problem with Ryrzy's rom... maybe the problem is on that one procedure I havent done?

Edited by eduuuuu, 04 August 2009 - 03:11 AM.

[shadowsjc]

i had the same issue on 6.1 with manila 2d installed.. it would close anything i opened if i had more than 3-4 apps running at the same time. i havent seen that yet on my current 6.5 ROM (bgill's' 1.4.2), but then again i also havent had too many apps open simultaneously.

[zman919]

Curiouser and Curiouser.

I don't think this is purely a RAM availability issue.  According to all the various docs I've read, a WM_HIBERNATE should be sent first in an OOM situation.  However, I don't see a WM_HIBERNATE hitting my test app.  I do, however, see a WM_CLOSE being sent immediately upon opening a second app.  So I have a situation that isn't following the spec, and isn't truly a RAM availability issue (I have well over 50MB available).

(*edit*  and it then gets killed outright by the shell via TerminateProcess(), despite the WM_CLOSE being caught and ignored by my test apps.  This follows the spec).

What I can't easily confirm is a resource availability issue.  However, if I wrap all my test apps in my Protector wrapper (ie, assign their windows to ToolWindow-based host apps), nothing gets closed  (which makes sense, since these apps don't receive WM_CLOSE messages).

Nothing falls down, either.  That is, if there was truly a resource availability issue building up, something should corrupt. I haven't run serious stress tests on this premise, but it's something to chase.

I wonder if there's a limit on the number of top-level apps (ie, those with traditional top-level windows) that can be running concurrently.  This would explain why I can continue to add service-type startup apps at will, but can't seem to run more than a couple sessions of simple test apps.

Down the rabbit hole I go.

Edited by zman919, 04 August 2009 - 03:56 PM.

[Root-dir]

 Preformance.JPG   78.76K   59 downloads
difference between the 6.5 and 6.1 in HKEY_CURRENT_USER\Performance

[zman919]

This is explaining some behavior I've seen with Palringo as well.  Palringo starts as a window-less service-type app.  When it gets an IM, it creates a window.  This window hangs around if the app is "closed"  (catches the close and instead deactivates the app).  However, the window probably expects a WM_HIBERNATE if there's a memory issue, at which point it would (I imagine), close the window but keep the service part of the app running.

However, what happens (I believe) is that it gets a WM_CLOSE and then a TerminateProcess().  This explains why Palringo runs idefinitely for me until I get an IM, and then quickly closes on me as I open another app.

This bug is freakin annoying.

[naynada]

zman919, on Aug 4 2009, 06:17, said:

Made somewhat interesting progress today.  I wrote a small app that injects a wrapper around target applications.  This wrapper assumes the role of the parent for the target app's window.  The wrapper itself is a tool window, and as such isn't subject to memory-based shutdowns from the OS.

It's pretty inefficient, but an interesting proof of concept. Working to clean it up a bit more.

An impressive analysis, zman

Well, if your app is successful, it will definitely benefit many, many people in the interim! (if MS decides/manage to correct this bug; otherwise, a long term fix =P)



If it's worth anything, after flashing a billion times between Sector, Khuanchai, Shokka, I finally have a somewhat stable setup, where I'm able to solidly run 2 apps simultaneously.

Funny thing is, after a soft reset it will gladly run 4 apps simultaneously (it'll kill a 5th app)...but after a period of usage it'll refuse to do so and limit itself back to 2 apps...

No. processes @ boot = 23 (including the taskmanager or memmaid) and RAM = ~58MB.

=/


Anyway, keep up the good work zman! =]

[vagika]

Hi,

It seems WM6.5 never kills igo.
It kills other applications randomly, even manila.
Is there a way to start apps like IGO?

Vagika

[JaGuR]

vagika, on Aug 5 2009, 11:48, said:

Hi,

It seems WM6.5 never kills igo.
It kills other applications randomly, even manila.
Is there a way to start apps like IGO?

Vagika

Any Idea of how many Apps we can get away with running before this bug comes into play ?

And being a bit of a Noob, does this not effect processes and just applications ?

Cheers

[zman919]

naynada, on Jul 13 2009, 11:59, said:

Yes, this is an incredibly irritating bug.

On WM6.1, I was able to listen to music (via S2P) and read ebooks (MS Reader) at the same time.

Now, on Sector's WM6.5, S2P will ALWAYS, without fail, close whenever I multitask anything at all.

Disabling HTC Taskmanager's AutoKill, and reducing the AutoKill memory threshold seems to have little/no effect.

However, at one stage, I did disable a couple of mortscripts which were sucking CPU cycles, and that helped a lot. But the problem has resurfaced, and I've no idea why.

A real pain in the ass. Hope this is resolved sometime.

For what it's worth, Conduit's PocketPlayer doesn't suffer from this issue.  It runs a separate, windowless thread for playback, so even if the window is force closed by WM, music continues uninterrupted.  Re-running PocketPlayer re-opens the window as it was  (this, by the way, is the "official Windows Mobile 6 Certified logo" approach to application self-management, as I've unfortunately become well-acquainted with over the last few days)

[zman919]

vagika, on Aug 5 2009, 11:48, said:

Hi,

It seems WM6.5 never kills igo.
It kills other applications randomly, even manila.
Is there a way to start apps like IGO?

Vagika

When iGo is minimized it closes its window itself and remains resident in a non-UI process.  This way it isn't subject to WM memory management. In all honesty, this is the correct way to write apps for WM, especially apps that are desirable to keep running "no matter what".

This is also the basis for the EverApp (lack of better name for now) utility I'm working on -- hooking existing windows to UI-less parent threads.

Edited by zman919, 05 August 2009 - 03:43 PM.

[zman919]

JaGuR, on Aug 5 2009, 12:47, said:

Any Idea of how many Apps we can get away with running before this bug comes into play ?

And being a bit of a Noob, does this not effect processes and just applications ?

Cheers

It only impacts applications that have top-level windows.  That is, windows that aren't owned by any other window. Some apps are smart enough to shut their window down when they're minimized (example, iGo).  In this way, they can survive indefinitely.  Likewise, services and service-type applications aren't affected.  A rule of thumb is, if they don't show up in Task Manager, they won't get nuked (some task managers show more detail than others, so this isn't always the case).

The spec for this behavior says that 2MB of remaining RAM is when the process begins to kick in. However, I don't think that's the case.  Also, it's not following the spec in terms of the type of termination messages sent....  so basically it's an unknown variable.

Edited by zman919, 05 August 2009 - 06:29 PM.

[zman919]

naynada, on Aug 4 2009, 23:39, said:

An impressive analysis, zman

Be impressed when I can fix it.  


So to recap, WM6.5 kills top-level window applications unexpectedly, violently and with (apparently) plenty of RAM available.  It's like a more malevolent version of the HTC task manager task killer.

I've tried every reg hack I could come across / think of, and none of them worked.  This includes...

Setting all the OOM reg values to zero
The DorkMemory/WM5 hack
The AutoOOM hack

I don't think it's a process count issue, because I can load up on startup apps and they all run without issue. I also don't think it's purely a window count issue, because early after boot I can run 3-4 windowed apps concurrently without issue, but after a while I'm down to 1-2.

I also don't see this is a classic OOM condition, because the WM messages aren't firing according to spec (that is, no WM_HIBERNATE is sent).  Perhaps MS changed the spec on OOM conditions....  but I'll be damned if 50MB free is an "out of memory" condition.

I also tested the notion of available RAM after bootup being some sort of threshold for this behavior.  I added a startup app that reserved 20MB, and then killed it after a couple minutes.  The problem persisted... so it doesn't seem to care about available RAM  (I noticed the Available RAM at Boot Time registry entry *did* include my artifical 20MB consumption).

So I'm back to EverApp... the utility I'm writing that re-casts an apps window as a child of a ToolWindow app  (which is immune from the window killer).  It's just very kludgy right now...   may not be something I can do in managed code...   we'll see.The other option is to decompile shell32.exe and/or coredll.dll and nuke whatever subroutine is responsible for this, but my skills at decompiling in the CF world aren't that great   (and the subsequent fix would require re-packaging into cooked ROMs, which I'm trying to avoid if possible).

Edited by zman919, 05 August 2009 - 06:41 PM.

[zman919]

Just an update -- the alpha version is done and functioning.  Will be stress-testing it tonight and hopefully releasing this weekend.

Z

[Jumba]

Thank you, am looking forward to your solution.

[Linkinou]

You WILL be a GOD

Quote

Just an update -- the alpha version is done and functioning. Will be stress-testing it tonight and hopefully releasing this weekend.

Z

[naynada]

zman919, on Aug 6 2009, 01:39, said:

For what it's worth, Conduit's PocketPlayer doesn't suffer from this issue.  It runs a separate, windowless thread for playback, so even if the window is force closed by WM, music continues uninterrupted.  Re-running PocketPlayer re-opens the window as it was  (this, by the way, is the "official Windows Mobile 6 Certified logo" approach to application self-management, as I've unfortunately become well-acquainted with over the last few days)

Ah, okay that's an interesting find. I'm actually using Nitrogen now though, as it's less CPU intensive than S2P.

zman919, on Aug 6 2009, 04:38, said:

Be impressed when I can fix it.  

...

So I'm back to EverApp... the utility I'm writing that re-casts an apps window as a child of a ToolWindow app  (which is immune from the window killer).  It's just very kludgy right now...   may not be something I can do in managed code...   we'll see.The other option is to decompile shell32.exe and/or coredll.dll and nuke whatever subroutine is responsible for this, but my skills at decompiling in the CF world aren't that great   (and the subsequent fix would require re-packaging into cooked ROMs, which I'm trying to avoid if possible).

I think we're all impressed by your efforts thus far as it is

"EverApp" lol - not a bad name =]

zman919, on Aug 8 2009, 06:01, said:

Just an update -- the alpha version is done and functioning.  Will be stress-testing it tonight and hopefully releasing this weekend.

Z

Ahh! The suspense! xD

[JaGuR]

zman919, on Aug 7 2009, 20:01, said:

Just an update -- the alpha version is done and functioning. Will be stress-testing it tonight and hopefully releasing this weekend.

Z

Thanks, am really looking foward to this

Great Work !!!

[zman919]

It.... is.... ALIVE!  

http://www.modaco.co...ce-under-wm6-x/