Microsoft Access 2010 started using 5-10% cpu when doing nothing. Why?

Question

We are running 32 bit MS Access 2010 Runtime in RDP sessions on 64 bit Server 2008 R2 Standard. For the past 3 months an Access application could be open doing nothing and the CPU usage would sit idle between 0 and 1%. Today the same test has it idling between 5 and 10%.

To rule out a change in the app, I created a simple app with just a form and one button, no form timer, or other running scripts. It had the same results. There were no installs or windows/office updates. Any ideas what may have caused this change or how to trouble shoot this?

This would not normally be an issue, but with 30 plus users running this as a remote app it kills the server. Please help!

Thanks

Answer 1

This may be Access 2010 related as I have about 40 users running and had no problems until I upgraded from Access 2007 to Access 2010. After that I began running into this issue.

We found we had the same problem due to I/O read/writes but they went away when we opened a persistent connection to the backend using a hidden form bound to one of the lookup tabkes.

Answer 2

This problem has occurred again. We now have a fix and posibly a reason, but not sure what to do for prevention.

The office runtime environment has been corrupted so a reboot of the server on its own is not enough to fix this. You need to repair or reinstall MS Access then reboot.

Although this may be coincidental, the problem coincides with the disconnection of a redirected printer. The remote desktop session automatically switched to another redirected printer as the default printer. All of this occured with the Access application open and potentially while a report was being printed to it.

Answer 3

Thanks for the reply.

We do have the TS locked down to a minimalistic desktop environment, and aero is not enabled. I've seen conflicts with Access and some graphics drivers before, but this does not or should not be the case here.

It is quite common to see TS fail to add a printer when connecting. However, I've never seen that cause an issue with Access unless we attempt to send to the printer directly which could hang Access.

I agree this will be difficult to track down. I may have to wait until it happens again to get the right information.

Not knowing scares me.

Answer 4

That is a mystery. I wonder if some virus scanning software was detecting "Access" or msaccess.exe, or in fact something was scanning "accdb" or mdb files in memory?

When I was doing some stress testing, I found that my results often varied just due to "Aero" glass being turned on, or off (it is a windows service by the way).

However, in your case, being a terminal server environment, I much doubt Areo glass would be an area to test or disable or even consider, but it was the issue in my testing, but that was a desktop computer – not TS.

One possible area could be the default printer. Many TS systems setup a default printer, and Access often attempts to "communicate" with the default printer which in your case could be the remote workstation connecting. So, perhaps checking default printer here, but really, this one going to be hard to track down.

Albert D. Kallal  (Access MVP)

Edmonton, Alberta Canada

Answer 5

By some miracle MS Access started acting normally around 4 AM today. I can't find anything in the system logs to indicate a problem or cause around the time it started or ended. There were no windows or office updates and no system or application warnings or errors. The closest thing to a possible cause is a critical error in msaccess.exe two days prior.

I would greatly appreciate any thoughts on how to figure out what happened.

Thanks!