If this helps any, I found that it was actually the "msflash.dll" component that was taking up the CPU (running under filesys.exe). I found a mention of this dll on MSDN and saw that there was a secure-wipe funtion that could be enabled, which I assume uses a random-bit erase function. It sounded like that could be it, since it would certainly take longer to erase files if that were enabled. I searched the registry and the key that enables the function is not there.
__________________ Dell Support Rep on 1/12/06: Only a small number of users are having issues (WM5 on x50v)... Dell will be releasing (update for x50v) but it will not be soon.
1-Hard-reset, delete all contents in BIS
2-Connect to ActiveSync 3.8 as guest
3-Install AS 4.1 - (I assume no USB connectivity issue here) avoid USB hub!
4-Perform the WM5 upgrade
5-When WM5 is up, Disable WM5 error notification
6-Install a Registry editor (e.g. Resco Explorer Suite)
7-Apply the registry hack for I/O cache performance and hack for CF disapearing
8-Make sure NO battery meters are active as today plug-in
9-Apply ActiveSync "fake server" hack
10-Install ActiveSync toggle (posted in the Wm5 is here..thread)
QUOTE]
Hi, so if i install wm5 following these steps will i not have the problem of my x50v running at 624mhz most of the time?
Hi, so if i install wm5 following these steps will i not have the problem of my x50v running at 624mhz most of the time?
No. You will still have the problem. There is no fix.
__________________ Dell Support Rep on 1/12/06: Only a small number of users are having issues (WM5 on x50v)... Dell will be releasing (update for x50v) but it will not be soon.
Connecting the platform builder Kernel Tracker to the Axim didn't work, but I found an interesting blog from a CE developer here: http://blogs.msdn.com/sloh/
Sue Loh talks about using "oscapture" to gather a log file that can later be viewed using the Kernel Tracker. I found the needed files among the PB stuff and was able to make it work. Now I have a kernel tracker window similar to the one Sue explains in her blog. You can pretty clearly see the activity in the thread in question. Not sure where to go from here. I am still left not really knowing what the thread is doing.
I also found some talk on the idea that WM5 "balances" the write pattern so that no single area of flash gets written more than the rest. The only way I can think of them doing that is to move stuff around so things that never change are relocated to allow their area of flash to be used by frequently-updated files. The end result might be that everything in flash is rearranged from time to time. If that is the case, this may be a necessesary evil.
Maybe the real problem is the prioritization and scheduling of this activity. If it could be arranged to happen only while cradled, for instance, it would make a world of difference.
In the PB version of filesys.exe I found one suspicious thread that had a top level loop like this:
VolumeCompactionThread() {
while (1) {
Sleep(0);
WaitForMultipleObjects(); // this is where the thread idles when things are good
DoStuffThatHogsCPU(); // this takes anywhere up to two hours and sucks batters when it runs
}
}
If I could get the axim version of filesys.exe and patch the Sleep(0) to something else (24 hours, for instance), it would result in this CPU hogging happening only every 24 hours, and hopefully at night in the cradle. Any idea how to patch a file in rom? The file doesn't even show up using ActiveSync and can't be read using explorer tools running on the Axim.
Maybe you can hack it in a rom file *.img or a backup file *.bis.
Then you can write to rom with AximUpdate.exe.
Good idea. I looked at the img file used in the original WM5 install, but it appears to be encrypted, or at least compressed. Surely someone has previously made tools for this sort of thing, perhaps in order to change the boot bitmap and such things on past roms.
Of course MS's new "security" system might also get in the way. If this file is signed (and it probably is) then patching it will break the signature...
I also found some talk on the idea that WM5 "balances" the write pattern so that no single area of flash gets written more than the rest. The only way I can think of them doing that is to move stuff around so things that never change are relocated to allow their area of flash to be used by frequently-updated files. The end result might be that everything in flash is rearranged from time to time. If that is the case, this may be a necessesary evil.
This is fantastic work -- thank you for researching this. Info on WM5's core is difficult to find; I've been hitting this 'msflash.dll' issue for a couple weeks now and haven't got much.
If the actions you describe are happening, that could completely explain what is going on. The OS sees the same files being written to repeatedly, so it decides to move them around to avoid premature ROM failure. This does sound like a good idea, but the effects of it are unacceptable.
I found some info that talked about the system doing a 'secure wipe' on deletions, which also could attribute to this problem. I didn't see the flag in the registry, but it could just be programmed in the dll.
Hopefully Dell will fix this, and give us enough tech info so we can see if we were on the right track!
__________________ Dell Support Rep on 1/12/06: Only a small number of users are having issues (WM5 on x50v)... Dell will be releasing (update for x50v) but it will not be soon.
i used Super tasks and from time to time i see the filesys.exe taking the 95% cpu and than i pull out the CF card and cpu goes down
i put the CF back in and the cpu remains down, and thats how it goes
so basicly no idea whats happening except BUGGY wm5
Did you install PocketBreeze when you met this problem?
I have been bothered by this problem for weeks. The filesys.exe sometimes would use up to 95% of cpu time.
For this reason, I have degraded and reupgraded my system for three times. For the first two upgrade, the problem appeared and I thought that was the bug of wm5(I installed the PocketBreeze 5.0(wm5 version) shortly after the upgrade).
The third time, I was quite happy because the filesys.exe did not bother me again during four days' test. So I decide to install all the softwares as usual. The problem happened again when I installed PocketBreeze. Moreover, when I uninstall Pocketbreeze, my x50v became normal again.
So I think this problem lies in PocketBreeze. Maybe there exists some special situations will make the filesys.exe act abnormally and it happen that PocketBreeze will trigger one of them.
How are you testing this on your device and which device are you using?
I would like to try and duplicate this on my side and see if I'm able to see the same behavior since I've never heard anything like that up to this stage, but maybe this is related to some configuration or software conflict, so I would like to test this as much as possible :)
Did you install PocketBreeze when you met this problem?
I have been bothered by this problem for weeks. The filesys.exe sometimes would use up to 95% of cpu time.
For this reason, I have degraded and reupgraded my system for three times. For the first two upgrade, the problem appeared and I thought that was the bug of wm5(I installed the PocketBreeze 5.0(wm5 version) shortly after the upgrade).
The third time, I was quite happy because the filesys.exe did not bother me again during four days' test. So I decide to install all the softwares as usual. The problem happened again when I installed PocketBreeze. Moreover, when I uninstall Pocketbreeze, my x50v became normal again.
So I think this problem lies in PocketBreeze. Maybe there exists some special situations will make the filesys.exe act abnormally and it happen that PocketBreeze will trigger one of them.
Noooo....I have had this problem and have never run PocketBreeze. I don't think it is related to any particular software running on the PPC. I have had the "slowbug" on my pristine upgraded x50v before installing anything.
How are you testing this on your device and which device are you using?
I would like to try and duplicate this on my side and see if I'm able to see the same behavior since I've never heard anything like that up to this stage, but maybe this is related to some configuration or software conflict, so I would like to test this as much as possible :)
I am using a X50v and I test in the following procedure:
1. Upgrade to wm5
2. Install a software and use for a while, if there is no problem, I will install another.
The sequence of softwares that I install:
1. Tweak2k.net - copy from previous installation without reinstallation
2. Language Pack for Chinese
3. Vidya.Pocket.Task.Manager.v1.0 - copy from previous installation without reinstallation
4. BryhtFlash 2.0 and Macrowave Flashplayer for ppc
5. Recso Explorer 5.30 (Without today plugin)
6. PocketBreeze 5.0 (in Chinese)
My x50v worked fine with 1-5. When I install PocketBreeze and soft reset, the filesys.exe became crazy and ate up lot of CPU. When I uninstall it, it became normal again.
I think the most suspicious conflict is the langage package if there is any. The following is the download link.
Follow Us
RSS Feed
Follow on Twitter
Facebook
YouTube
