The msflash.dll thread uses hardly any CPU under normal circumstances. This gives me some hope that it is a bug, not a characteristic of this type of storage.
In googling around for msflash.dll I found some discussions and registry settings that mention a "compaction" thread that runs inside filesys.exe. I wonder if that is it? Maybe WM is doing what amounts to a "defrag" of the ROM in order to "help" us and to give us "better performance". Unfortunately, the defrag process is worse than the problem it tries to solve. Just a guess... whatever it turns out to be, surely it will eventually be fixed, either by MS or by Dell.
I think we may be able to figure this problem out before Dell does. :)
What would be the point of defragging ROM though? Isn't fragmentation only a problem for a device with a movable parts (hard drive)? Unless there is some driver limitation, I would think that the system could read from ROM sequentially regardless of what registers the data was stored in.
__________________ 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 downloaded the tools from that xs4all site, and have confirmed the msflash.dll as being the resource hog. I can't find a lot of information on it, a Google search only returns 4 results.
I'm going to keep investigating this, I need to get more information on what tasks the dll is working on. Maybe if there was a way to query that specific process and see what files it was hitting?
__________________ 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 couldn't stand wm5. Rollbacked to wm2003se. I Mainly use it for Navigation and the software would just hang with wm5. Everything else was slow on my X50v. So glad I'm back on wm2003se. Its really stable and fast. Besides the candy benefits of wm5. I don't see any advantage for my purpose.
I downloaded the tools from that xs4all site, and have confirmed the msflash.dll as being the resource hog. I can't find a lot of information on it, a Google search only returns 4 results.
I'm going to keep investigating this, I need to get more information on what tasks the dll is working on. Maybe if there was a way to query that specific process and see what files it was hitting?
I am wondering about this theorie of msflash
1-Since I can't not tell how much CPU utilization that filesys.exe takes and when. But I know when ActiveSync kicks in, you feel the spike and the Axim hangs for few seconds. I assume these 2 events are correlated.
2-The "fake server" hack seems to mitigate the issue, since ActiveSync is not invoked unnecessary. Perhaps filesys.exe is not invoked for the same reason.
3-Munk's "Registry hack" seems to be effective and MSFlash is involved as below indicated:
HKEY_LOCAL_MACHINE\System\StorageManager\FATFS\Cac heSize=4096
HKEY_LOCAL_MACHINE\System\StorageManager\FATFS\Ena bleCache=0x1(1)
HKEY_LOCAL_MACHINE\System\StorageManager\Filters\f sreplxfilt\ReplStoreCacheSize=4096
HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\ MSFlash\FATFS\DataCacheSize=0x1FA0(4096)
HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\MSFlash\FATFS\Flags=0x28(40)
Just a thought!
__________________
The Lighter Side of Mobile Technology
To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
X51V To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. Latest News, Tips, Skins, Podcasts, Videos,..Visit To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
You know, I didn't think the A/S fake server thing was the solution and I was hesitant to try it because I thought it caused some A/S problems I was having earlier. I did it three days ago and it didn't seem to work at first but I've noticed over the last two days that I have not had the CPU max out ever when it used to happen at least every 4-6 hours. Comincidence maybe but if you have NOT tried it, go ahead and do it. You have nothing to loose and it could just be the answer.
:attn: ****NOPE IT IS DOING IT AGAIN ****** Still don't have a reason for this. :headshake
You can monitor the processes, and you'll know for sure what's going on with your Axim.
__________________ 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.
You know, I didn't think the A/S fake server thing was the solution and I was hesitant to try it because I thought it caused some A/S problems I was having earlier. I did it three days ago and it didn't seem to work at first but I've noticed over the last two days that I have not had the CPU max out ever when it used to happen at least every 4-6 hours. Comincidence maybe but if you have NOT tried it, go ahead and do it. You have nothing to loose and it could just be the answer.
Yeah the AS fix was successful in preventing AS from starting on my X50v every few minutes. However, this did not solve the high CPU usage on my PDA overall. It appears to happen less frequently, but something else is still going on. Also, the AS fix does not stop my X50v from turning itself on every few min when docked w/ my PC.
Lots of good fixes on these forums for the various WM 5.0 issues. Unfortunately, I haven't spotted a good one for the CPU usage issue yet. :(
I still think it is related to notifications also. Half the time my PPC got hot and used a ton of battery while off when I turned it on there was a pending notification.
This does scare me a bit though, since it is the msflash.dll that is causing the load. I'm pretty sure this is the dll responsible for the ROM reads/writes, and maybe there isn't a way to fix it. This could be the "warning" about the downfalls of persistant storage, finally realized on a functional level. Is that process working in the background to write all of the ROM requests that were queued? Is this the necessary evil of WM5?
If this was really a problem of WM5, then it would affect all devices running WM5, wouldn't it? As far as I know, this slowdown problem only afflicts the Dell x50 series. Must be a Dell implementation/driver problem, not an OS problem.
I have to eat crow, mine is doing it again so the A/S fake server DID NOT SOLVE THE PROBLEM.
I've had this problem kick in without any reminders. I think it is a bug in the drivers or something but I'll keep messing around with it on the off chance that I'll get it fixed for good.
If this was really a problem of WM5, then it would affect all devices running WM5, wouldn't it? As far as I know, this slowdown problem only afflicts the Dell x50 series. Must be a Dell implementation/driver problem, not an OS problem.
It isn't necessarily a problem with either the device or the OS, just the melding of the two. The ROM in the x50 was designed to be written rarely, and read often. The WM5 OS is using that same ROM as a write often, read often, and maybe it just can't hold up. I haven't looked at the specs on the HPs, and what type of ROM they use, so I can't be sure.
We are all just taking stabs at what might be the problem here. None of us really know for sure since we don't have access to the source code.
__________________ 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.
Follow Us
RSS Feed
Follow on Twitter
Facebook
YouTube
