100% CPU Bug, not Outlook

[jstackpow]

Edited by WyllyWylly to add URL code and remove whitespace. <img src=/S/smile.gif border=0 alt=smile width=15 height=15>

The 100% CPU redline bug is not just for Outlook users - we all can share! it!

I don't run Outlook.

In my case it shows up only when I do a Palm HotSync - CPU goes to (nearly) 100% and stays there (at 95%) even after HotSync is finished and even exited from. Obviously some loop has been set up in the system, that stays on. System restart cures it, of course.

Problem began right after the three recent M-Soft "Critical Updates": Q328970, Q329115, and Q329414. Dunno which one, but I suspect Q329414 as it deals with data access (where I/O loops come from) and it has been reappearing on the critical list every day, ever since, even though the installation is reported as "successful". Bad code, bad installation, I suppose.

I think that M-Soft is out to get me - they must have found out that I recently bought a new iMac for my wife...

Other than paranoia, any suggestions?

[WyllyWylly]

John,

A curious question: are you using the latest version of the Hotsync software, or the one that came on the installation CD with your Palm? I've had several strange issues with the older versions of Hotsync on Windows 2000, and they have been almost completely resolved (almost) by upgrading to the latest version from Handspring's website. Give that a try first and see if it helps (if you haven't already).

Edited to add: After doing a bit more research, I thought about the statement regarding article 329414. You may want to download MDAC 2.7, the most recent release - reinstalling MDAC may go a long way towards fixing odd problems. Download MDAC here: http://www.microsoft.com/data, and make sure that you also get the latest Jet components here: http://www.microsoft.com/data/download_Jet4SP3.htm as they work together.

<hr>I think that M-Soft is out to get me - they must have found out that I recently bought a new iMac for my wife...<hr>

Maybe not - after all, Microsoft themselves propped Apple up a few years ago so that they could look the government square in the eye and say "See? We have competition...no really, we do..."

Ed. note: I'm sure to be flamed roundly by Mac fans for that statement but it's true!

[jstackpow]

Am currently using HotSync 4.1.0, and have been for many months - it came with the Palm Desktop upgrade to 4.1, some time ago.

HotSyncs have been trouble free right up until the MDAC "critical update" - Q329414 - and the others I mentioned. All done at once last week. Will go and try your MDCA 2.7 suggestion, and let you know what comes of it. Thanks.

[jstackpow]

Oh dear... no luck...

Turns out I already had MDAC 2.7 installed (from a year or so ago). This was verified by running the MDAC Component Checker code (from the same /data page that you pointed me to).

Given that I have 2.7 installed, why was M-Soft sending me "update notices" that said they pertained to MDAC 2.1 - rhetorical question.

Anyway on the off chance that the Q329414 update might have damaged MDAC 2.7, I went ahead and re-installed 2.7 from the git-go. But to no avail. HotSync still left a 95% CPU utilization in its wake, that would not go away.

Oh well... Thanks. Maybe I'll try something else.....

[WyllyWylly]

Can you remove the patch? You might also try re-installing Hotsync to repair any damaged files/conduits.

[Phil Rabichow]

<hr>Microsoft themselves propped Apple up a few years ago so that they could look the government square in the eye and say "See? We have competition...no really, we do..."
<hr>

You mean you don't think that Microsoft helped the competition for truly altruistic reasons? I'm crushed. <img src=/S/flatcat.gif border=0 alt=flatcat width=61 height=21> I wouln't have dreamed they had an ulterior motive. <img src=/S/sarcasm.gif border=0 alt=sarcasm width=15 height=15> <img src=/S/rofl.gif border=0 alt=rofl width=15 height=15>

[jstackpow]

Been....Done... but I appreciate your help....

The MDAC Patch is "uninstallable" but I discovered a log file that the install code wrote (dahotfix.log) which indicated that the security patch was NOT installed at all after all - the install code checked, discovered I had MDAC 2.7 installed and skipped over things, sayeth the log file.

So I've been barking at the wrong tree, perhaps. Maybe something in the other two critical updates (Q328115, Q328970) which went in at the same time, is the problem. We'll see... (but I don't quite know HOW I'll see...)

[jstackpow]

Now Quantum Physics is getting into the act - at least the part where making the measurement influences the thing being measured...

If I am RUNNING System Monitor (to keep an eye on CPU usage) when I do the HotSync, the CPU usage jumps to 95% after HotSync is finished.

If I run SysMon to look at the "quiet" machine CPU usage (20 % or so), exit SysMon, run HotSync "alone", then run SysMon again, the CPU usage goes up, but only to 40%-50%, staying there after Hot Sync finishes.

Go figure!

[WyllyWylly]

That has the distinct odor of a memory leak. Disable everything you can prior to running the sync and see if the same or similar happens - that includes AV software, anything running in the background....you could also try disabling conduits in the sync application and re-enabling them one at a time to see if it has something to do with an app that you are synchronizing with.

Heisenberg

[jstackpow]

Maybe I am missing something (or demonstrating profound ignorance) but I thought memory leaks had to do with, well, memory. But the problem I see is CPU utilization. MemTurbo appears to clean out any reserved but unneeded memory, set aside by previously running programs -- isn't that what "memory leak" is all about? -- but doesn't "free" the CPU from whatever computation is going on -- some sort of loop? -- after HotSync finishes and exits.

Thanks, JDS

[WyllyWylly]

You're correct in thinking that memory leaks have to do with memory. Specifically, a memory leak occurs when a program does not properly release the resources it uses back to the system pool. As less memory becomes available for general system use, the CPU ends up with a higher load and can spike.

Personally, I've had problems with programs like MemTurbo. Although the premise is great, memory managers tend to be designed either more strictly than Windows own ability to manage system resources, or not as efficient and sometimes downright buggy. I've found it's much better to allow Windows to manage memory on its own rather than to have a separate process executing that could interfere with it. In the days of DOS, memory managers served a better purpose, since DOS and early versions of Windows weren't all that great at doing the job on their own. In the modern era of 32 bit computing with a CPU running in protected (as opposed to flat) mode, along with the things software developers have learned since then, they're largely unnecessary. QEMM for Windows caused myself and some colleagues immeasurable amounts of grief!

A memory manager may clear out reserved memory, but quite often the same process will reload or the same code will be needed, and it's substantially faster to grab it from cache or memory than to start from scratch. This principle is vividly demonstrated with the CPU itself - try disabling the CPU cache in BIOS, start your system, and watch what happens. This is the same thing that MemTurbo and its brethren do on a higher level once Windows loads; dumping code immediately instead of letting it be managed on an as-needed basis. If Windows 98 isn't releasing resources as it should, it's almost certainly a bad device driver or program (VXDs, or kernel level drivers, are notorious for breaking the rules). Win95 had issues, but many improvements were made in 98's design as a direct result of that.

Although I hate to admit it, in the end it may be more time-effective to start with a fresh installation rather than hunt down the elusive problem. Let's hope it doesn't get that far. If you're running a separate memory manager, I'd strongly suggest disabling it and seeing what happens. For tricky problems like the one you're experiencing, the best (albeit the most painful) way to troubleshoot is to eliminate everything you possibly can - other processes, anything that can be considered a variable - and then let them back into the sandbox to play until someone starts a fight.