Windows 11 Slowing Down Database

Weekleyba

Registered User.
Local time
Today, 03:00
Joined
Oct 10, 2013
Messages
593
I have a split database that we use with 12 people.
Recently IT "upgraded" two computers from Win 10 to Win 11, mine being one of them.
The performance of the database is significantly slower. Each click taking 5-15 seconds with the database showing "Calculating..." for up to a minute.
Currently running Office Pro 2021.
The other individual is experiencing the exact same issue.

Note however, if no one is in the database and only I open it up, it runs great. The minute someone else opens it, it slows way down. This has always happened but not to this extent. I have another laptop with Win 10 and it runs much faster comparatively.

Can anyone help?
 
If you check the Start (lower-left button on task bar) >> Settings >> About, see if you are running Win 11 v 24H2, which enables Bitlocker by default. The patch that enables Bitlocker will try to install it if you don't have it, or so I've heard.

IF you have 24H2, use the Start button again but this time, in the search field at the top of the panel, type Bitlocker. That will let you look at how it is configured. See if you can turn off Bitlocker if you appear to have it and it is enabled. I found quite a few articles online about how Win 11 really bogs down Access and other programs and it was centered on Bitlocker encrypting and decrypting the world.

If your IT people FORCED you to use Bitlocker, this problem MIGHT not be solvable. However, if your IT folks allow it, it should be possible to disable Bitlocker. If you can turn off Bitlocker, it should decrypt things for you. Once it does that, there is a fix online to permanently disable Bitlocker. The articles I saw guide you to enter a registry key that will forbid further Bitlocker activity. One thing that the "anti-Bitlocker" registry-key fix does is it balks the ransomware folks who will try to encrypt your hard drive by triggering Bitlocker with a non-standard key.
 
Thanks Doc. I will see what IT says. Hopefully they will try this, the database will become painful to use without a fix.
 
Please also note, this might NOT be Bitlocker. I just responded with the results of a search that found several references pointing in the same direction. I don't have the problem because as soon as my Win 11 came up, I started disabling a lot of the more egregious "personalization" features and hidden "security" features that would have been system hogs. Since you have a new Win 11 installation, you also need to look into turning off and/or disabling the RECALL feature that is driven by Co-Pilot. That feature would have the effect of eating a lot of disk space and putting a big load on your disk. It also involves doing a web search on how to block that particular beast, which takes a screen snapshot every several seconds and uses it for personalization - translation: trying to "anticipate your needs" - while surreptitiously building a consumer profile that they can sell to various and sundry advertisers.
 
So IT turned off the Bitlocker. I restarted twice and tested twice. Still the same slow performance result.
I've sent IT your latest suggestion, maybe they can work on that RECALL feature and turn that off.
Thanks for your help!
If you have any other thoughts, I'm all ears, since I really need to get this running faster or it will probably die.

Is it possible that Bitlocker would need to be turned off on the Server where the BE resides?
 
How is everyone connected to the BE Hardwired LAN or WiFi?
 
suggest open task manager, sort by name and check whether you have multiple instances of the same app open- seems there can be a lot more apps open taking up memory, particularly AI.

So it may be a memory issue?
 
suggest open task manager, sort by name and check whether you have multiple instances of the same app open- seems there can be a lot more apps open taking up memory, particularly AI.

So it may be a memory issue?
Only shows one.

1744995630688.png
 
If the problem isn't Bitlocker, then you have to try to diagnose this problem through a more tedious process. This article might help.


Looking for what is different becomes difficult because you suggested your upgrade was only the version of Windows, not the version of Office. And of course, the version of the app is the same, too. So this is something to do with either the O/S or the support library.

If the Win11 situation had totally failed, that might have been easier to test because there would have been a task failure in the system error logs with some pointers to which task and subtask failed and why. But the fact that the Win11 systems work - just slowly - means this might be a simple performance bottleneck somewhere and those are notoriously difficult to find.

I doubt it is a permissions issue because again, your tasks work. Just slowly, but they get through. The version of SMB protocol (v1, v2, or v3) could do that, but the effect is something that would have shown up if you were getting regular Win10 updates when they were still available - because SMB v3 came out several years ago. The other factors that usually come into play would include whether the tables in your DB were supplied with decent indexes and whether anything was odd about the queries. But again, that would have shown up under Win10 as well. The observation that sticks out is that (a) Win10 systems on your network work better than Win11 and (b) when your Win11 is single-user in that file, it works better.

When you/IT loaded Win11, you had to reset the networking configuration which means you have also reset the routing tables. You might need help from IT for this, but I would use the CMD-line utility TRCROUTE to trace the path from work-station to back-end. Particularly if you still have a Win10 on the same network sub-segment as your Win11 machine, that should allow for an apples-to-apples comparison.
 
you are using 13% of CPU. I can only see 4.9% from your screenshot - scroll down (or sort) to see what else is using the other 8% of the CPU

Similarly you are using 49% of memory - but don't know 49% or what. You are showing about 1.8gb. Assuming you have 16gb memory, something is using around 3 times that amount.

Compare with other machines to see if you have similar figures.

Also check before and after someone else connects to see what, if any, changes occur.

And clarify your setup as it is not clear. Each user should have their own copy of the FE on their machine, whilst the BE will be on a network server. If you are all using a FE that is located on the server, that also will be an issue. And is everyone using the same version and bitness of Access?
 
Last edited:
you are using 13% of CPU. I can only see 4.9% from your screenshot - scroll down (or sort) to see what else is using the other 8% of the CPU

Similarly you are using 49% of memory - but don't know 49% or what. You are showing about 1.8gb. Assuming you have 16gb memory, something is using around 3 times that amount.

Compare with other machines to see if you have similar figures.

Also check before and after someone else connects to see what, if any, changes occur.

And clarify your setup as it is not clear. Each user should have their own copy of the FE on their machine, whilst the BE will be on a network server. If you are all using a FE that is located on the server, that also will be an issue. And is everyone using the same version and bitness of Access?
Here's a larger screen shot. It is probably 8 times as long as this. One is sorted for Memory the other for CPU.
I also closed everything I could except Access.
Very similar on the other computer with 7% CPU and 32% Memory.
Set up is everyone has a FE on there own computer. BE on the server.

I would to check if everyone has the same version and bitness of Access. Not sure on that one.



1745000596400.png




1745000826730.png
 
it was just a suggestion - I've experienced slow performance when CPU/Memory is those sort of levels but looks like that is not the issue here
 
I have taken over a long running Access database with almost the same sorts of issues, so it might all be the same. With one user in, it is fine, but when more load it, the performance dive-bombs far more than it would normally do. Same issues with sticking on Calculating etc and is truly not consistent either. You can run one report 4 times and it loads in 20 seconds, try it again and it could sit there for 45 minutes (code still trying to run and no timeouts/errors). It can also be faster/slower on different days with no real flag of what is different.

The database used to work fine up until maybe a year or so ago (they aren't really sure). They are on Windows 11 with Bitlocker on locally and on the server drive. I don't really know when they upgraded everything.

The installation is a bit of a mess and in regards to the server very much not installed to best practice nor licence compliant, but that is run by another IT support company at the moment (they won't even consider it is any issue related to the server, the network or them!). There are so many things to be considered and tried with this install, but the database itself is getting the blame.

Interesting to see the difference in this one in the same environment only when Windows 11 came on board. Some things locally have been tried in terms of disabling AV on server and workstations.

My thoughts were more aimed at the server setup, given it is a mess and Server 2022 - I was going to start to look at disabling RSC, VMQ and so on, on there in case it was the 2022 networking stack causing the issues. It does make me wonder about differences in the Windows 11 network stack like CUBIC etc now though.

However, until spotting this thread, I hadn't seen any other similar issues mentioned in searches.
 
Your description doesn’t say how the app is installed. It should be split, a copy of the FE on each users local machine linked to a BE on the server. If it isn’t then that can cause the issues described
 
Your description doesn’t say how the app is installed. It should be split, a copy of the FE on each users local machine linked to a BE on the server. If it isn’t then that can cause the issues described
If that was for me, yes definitely a split as I would always do, although I inherited multiple back end files. I have lots and lots to try and deal with on this one each of which opens new cans of worms. Obviously no referential integrity, but I have also checked and adjusted indexing and more. No record locking on it either.

I have been developing in Access for over 25 years and never really seen the like of either the development of this particular database or this type of issue, and as you can imagine, I have seen my fair share of issues and poor development. I don't think the issue has much really to do with the development as such as I have tested all the back ends being combined to one BE and more or less everything you can think apart from Windows 10 (as they don't have any, any more), or the BE on a different server or NAS.

The fact this initial thread showed a marked difference in performance between Windows 10 and 11 was also the first time I have heard that in the field with any of my clients, but may point my investigations that way (why this client would be any different unless something combined with the peculiar network/server setups, I don't yet know).

There are reasons in the development that explain why certain elements of it are slow and those will get redeveloped over time, assuming the client doesn't give up on it, but those should still all be consistent and not how it is at the moment. That smacks of something external to the database to me.
 
In addition to the comments above regarding BIT Locker and Antivirus, there is another overlooked area within access itself that affects performance. If you have compression enabled, that could also lead to performance issues.

As for anti-virus, a lot of System Admins like to blame software for their weaknesses, and a lot them are highly prejudicial on Office Products, especially Access. They will implement Anti-virus and harden it to the point where applications just stop functioning or become terribly slow. Access itself is not the culprit. A trusted application should be placed in a trusted location where there is no pro-active defense. I personally do not run any 3rd party anti-virus software. I rely entirely on built-in windows security. I have had nothing but bad experiences with all the popular 3rd anti-virus software, mainly regarding performance of office products.

Also, if you are running any Emulator Software, make sure your Office components have been updated. Older Emulators like to install office core dll's in the older folder structures. The problem is this cause ambiguity when certain functions are called.

I am not sure why or how upgrading from Windows 10 to 11 would affect this, but it is worth looking into. Make sure the "Name AutoCorrect Options" are disabled in your production application. Thise feature is enabled by default in new Access Databases. This feature tracks name changes to objects and can track in run mode if enabled.

1747751849676.png
 

Users who are viewing this thread

Back
Top Bottom