Guest zman919 Posted August 5, 2009 Report Share Posted August 5, 2009 (edited) 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 August 5, 2009 by zman919 Link to comment Share on other sites More sharing options...
Guest zman919 Posted August 5, 2009 Report Share Posted August 5, 2009 (edited) 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 August 5, 2009 by zman919 Link to comment Share on other sites More sharing options...
Guest zman919 Posted August 7, 2009 Report Share Posted August 7, 2009 Just an update -- the alpha version is done and functioning. Will be stress-testing it tonight and hopefully releasing this weekend. Z Link to comment Share on other sites More sharing options...
Guest Jumba Posted August 7, 2009 Report Share Posted August 7, 2009 Thank you, am looking forward to your solution. :) Link to comment Share on other sites More sharing options...
Guest Linkinou Posted August 7, 2009 Report Share Posted August 7, 2009 You WILL be a GOD Just an update -- the alpha version is done and functioning. Will be stress-testing it tonight and hopefully releasing this weekend. Z Link to comment Share on other sites More sharing options...
Guest naynada Posted August 8, 2009 Report Share Posted August 8, 2009 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. 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 =] 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 Link to comment Share on other sites More sharing options...
Guest JaGuR Posted August 8, 2009 Report Share Posted August 8, 2009 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 !!! Link to comment Share on other sites More sharing options...
Guest zman919 Posted August 9, 2009 Report Share Posted August 9, 2009 It.... is.... ALIVE! :) http://www.modaco.com/content/pocket-pc-so...ce-under-wm6-x/ Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now