LAN Windows 11 24h2 Slow performance

[RL92]

There is a SQL server over LAN with about 10 PCs connecting to it with Access frontend.

At some point 3 new PCs with Windows 11 were acquired. At first they were all running smoothly and faster than older PCs (as claimed by users).
After several months one of those PCs started choking on the access frontend. About two months later 2 remaining new PCs started to lag as well. After that I pinpointed an issue to the 24h2 update (I am still 99% sure about that).

At this point rollbacks to 23h2 are impossible.
Frontend still works smoothly on Windows 7.
It seems even a bit faster on wifi connection (vs Windows 11 cable).
The only PC with Windows 10 is also slow (though it was always a "weaker" and "slower" piece of hardware).

What is more the same SQL server is also hosting a database for a different application (licensed, probably c++/c# based) and it works smoothly on new PC with Windows 11.

I tried some googling back then but I was unable to solve an issue.

I would like to give it an another try because Access frontend seems like an actually good option for a small office.

Thanks for any help.

 

[Gasman]

See what updates were applied to Access as well?

 

[Minty]

What Version of SQL server and what ODBC driver are you using to connect to it?

 

[The_Doc_Man]

I don't have any advice on what to do, but here is a list of issues from Microsoft Learn regarding the troublesome 24h2 update.

Windows 11, version 24H2 known issues and notifications

View announcements and review known issues and fixes for Windows 11, version 24H2

learn.microsoft.com

 

[GPGeorge]

I've been trying to recall an issue with Access back ends on network shares that was possibly associated with the 242H2 update.

The only thing I come up with is that it had something to do with needing to disable leasing. Maybe someone will know what I'm talking about and can address whether I'm actually thinking of a relevant issue or not.

 

[dalski]

Sorry to hear this:

• As @Gasman suggestion you can access Access update history via File > Account > below
• I know you said rolling back Windows is not an option but just in case; a previous version

Another update causing more problems than they fix . This is so, so, bad, no wonder they appear to have lost 400 million users since Win 11. I am absolutely terrified about this, please update if you manage to fix & what it was.

 

[The_Doc_Man]

The only thing I come up with is that it had something to do with needing to disable leasing.

I believe that relates to SMB protocols.

Solved: Disable SMB Leasing again | Experts Exchange

Find answers to Disable SMB Leasing again from the expert community at Experts Exchange

www.experts-exchange.com

In essence, when you are sharing files across a network, you use buffers. There is some trick that for non-SMB connections can optimize the speed of the network exchange regarding those buffers. This is a problem for ALL protocols that deal in disk "allocation units" (a.k.a. "storage clusters"). Allocation units are bigger than the standard network buffer size (either 4 or 8 Kby for allocation unit, about 1.5 Kby for network) so the buffers must be broken apart and transmitted piecemeal and then reassembled at the other end.

However, for SMB protocols, leasing has the side effect of delaying writeback to the network partner. When this delay happens, one of the possible effects is an otherwise inexplicable DB corruption. Other conditions have been detected including "hangs" and "non-visibility of shared files that SHOULD be visible remotely" and a few other nasty results, usually caused by having to wait for fragmented buffers to be reconstructed.

You might have to search a few articles to find the Registry Key entry to disable SMB leasing. By now, particularly if you are on Win11, you should be using SMBv3 protocol, which has several leasing options. You want to disable leasing entirely if I understand what I read.

 

[Albert D. Kallal]

First up:
>>there is a SQL server over LAN

Ok so file sharing, locking etc. not going to be the issue here, then right?


>>I pinpointed an issue to the 24h2 update

Really?

Well, if this was a wide spread issue due to that update, then would not the internet light up like a Christmas tree then?

Since everyone else is not seeing this issue?
Then we have to start narrowing down this issue.

Given that some machines can and do work just fine (performance wise)?
Then we can quite much rule out that SQL server is not the issue.

And since when the update occurred, not every machine "in an instant" started running slow, right?

But, a HUGE hint of "slowing down" over time? That's never much due to ONE windows update, right?

So, REALLY good guess would be the ODBC drivers have sql logs turned on.

This thus makes the ODBC driver slow, and run slower and slower over time as the log file grows.
(this log file is client side - not to be confused with SQL server log files - but as noted, if this was SQL server side, then all users would be slow, and you reported this is not the case!!!!).

So this "smell" hint of slowing down over time?
That's not a windows update issue - can't ever remember such a symptom with the "over time" slowing down issue, right!

If a windows update slows things down, then it slows things down right after the update - not "over time", right???

But, before we deal with the above? (but, you could quick check the ODBC driver settings on a machine that is slow)

We need the following information:

You note about 10 users -- good, ok!

Does each work station have its own copy of the front end (FE), or is this a shared FE?
(now above is MUST HAVE information before we continue)

And how are you linking? - SQL server passwords - DSN less?
Or domain users? (again, MUST HAVE information before we continue)
(and what version of ODBC driver are you using?)

So, we need the above info answered FIRST before we start going down too many rabbit holes....

R
Albert

 

[RL92]

Thanks for all responses.

I will try to add as much information today. More will be verified/added next week (I will also update opening post).

By "over time" I meant different thing:

• Apr 2024: Three new PCs were added (let's call them A,B,C). Program works smoother and faster on those PCs than on older Windows 7 machines. Users are happy.
• Oct 2024: User A (heavy program user) signalled a slowdown (sudden). User B (another heavy user) had no issues.
• Dec 2024-Jan2025: I spend some time trying to solve that. I actually found some implications that 24h2 could be problematic and I checked update history (and update happened in Oct).
• During this time User B was still actively and happily using a program (even inherited tasks from user A).
• Feb 2025: It was reported to me that User B updated their PC and faces the same issue.
• Apr-May 2025: I gave it an another try with no success.
• As of PC "C" I have no timeframe data because user C rarely uses a program. I am certain that at Dec 2024 it was working fine and at Apr 2025 it was laggy.

What is more I didn't add any new functionality at that time.

I am not certain that it is 24h2 fault. I can't be. There was indeed little to be found on the internet... which is the biggest issue. Though there were some other people pointing at 24h2 (can't link because of spam filter). It is my guess that it may be something specific with a combination of 24h2 update.

All users have their own FE copy at their own PC (no one-drive, no other cloud, no lan drive).
Linking: DSN less, SQL password (one user).
ODBC driver: I am using "SQL Server". I tried both "ODBC Driver 17 for SQL Server" and "ODBC Driver 18 for SQL Server" - no noticeable improvement. I can't check neither versions nor settings right now.
SQL Server: I am almost certain that it is 2019. To be verified. And it seems fine (works ok for windows 7 stations, works fine for other licensed program at windows 11 stations). It is hosted at windows 7.

ODBC tracing is not turned on (are those drivers' sql logs?).

Some other things I remember trying:

• Reinstalling Microsoft Office 365.
• Installing Access Runtime 2010 (and running program on that).
• Updating network drivers (note that all 3 PCs have "identical" hardware). At first I thought that one PC had some faulty hardware.
• Disabling bitlocker.
• Compact and repair.

I believe there was SMBv2 and I remember doing something in registry. However I will obviously give it another try.

Reading the topic at experts-exchange gives me familiar vibes. In fact my main performance check is based on reattaching/relinking tables. I remember that once after I restarted problematic PC, an Access program turned on properly (within 1-2 second all tables were reattached). However a minute later it went back to 30s load.

Thanks again.

 

[The_Doc_Man]

I believe there was SMBv2 and I remember doing something in registry. However I will obviously give it another try.

SMB v2 introduced "reservations" as an optimizing tool/technique. I t have a direct link in my earlier post. Or you can do a great-Google-brain search to find out about "SMB protocol reservations" to get a foothold on that topic.

The thing you did in the registry PROBABLY was to edit the registry option that controls the "reservations" feature - by turning it off. That reservation feature has been linked to issues with Access, which uses SMB quite heavily - in fact, depends on it. More precisely, Access depends on SMB but not on the reservations feature of SMB. We are probably on SMB v3 so the registry key for that may have changed. I'm not in a position to evaluate that fine point because even my wife's PC running Win10 is on SMBv3.

 

[RonPaii]

I believe there was SMBv2 and I remember doing something in registry. However I will obviously give it another try.

If the BE is on SQL server then SMB would not be the issue.

 

[The_Doc_Man]

If the BE is on SQL server then SMB would not be the issue.

Good point, Ron. Access uses the file-sharing protocol SMB and the FE performs the work, directly updating the BE using "remote file system" operations. SQL server uses some variant of an ODBC driver, which is a different protocol. The server processes packets sent through the device driver and the server works on the DB files. The FE does not directly touch the server's files.

 

[Minty]

If you are using SQL server Ver 2019 then I would update everyone to at least ODBC driver 17 and preferably version 18.
Even if it doesn't fix the immediate problem, it is much more stable and handles dropped or interrupted connections in a much more elegant fashion.

This could be a network issue. We have seen some clients where network traffic causes slowing down and it can be quite random in what it affects. One particular client had a dodgy switch which just happened to connected to their NAS storage box which caused no end of problems.

Can run the FE on the server?

 

[Albert D. Kallal]

Excellent follow up. 5 stars for you!!

Appreciate the concise, but fantastic information you provided so far (well done!!!)

By "over time" I meant different thing:

Ah indeed, again your follow-up clears this up – (so, over time is you having to deal with this issue, and seeing the issue crop up – again excellent clarification).

ODBC tracing is not turned on (are those drivers' sql logs?).

Again, good, and no logging. For those reading this, this is the "driver" logging, not SQL server logs.
(this when setting up the ODBC driver connection).

Ok, so we down to slim pickings.

One thing to check?

Check if ANY report has anything set other then “default” for the printer. Often if a stray report has a printer setting that does NOT exist on a given workstation, then often Access will attempt when loading a form (or report) – even ones having nothing to do with the “stray” report?

Then access will attempt (request) information about that printer, and of course if the printer does not exist, then you get that delay/hang.
And if default printer is a network printer - again, same issue....

So, for any workstation that does not have a printer (probably most of them), try ensuring their default printer is NOT a network printer, but say the local PDF printer. (or print to pdf).


So, workstations without a printer.

So, workstations who have default printer = some network printer (don't do this)

(change this to local printer for testing – see if it helps).

So, access reports fixed/set to a printer that does not exist.

So, you need/want to check if any reports have anything “different” then "default" for reports printer.


So far?

My bets are:

You suspections may well be correct – it’s something to do with that windows update.

Or

The default or missing printer(s) issue…….

R
Albert

 

[RonPaii]

So, for any workstation that does not have a printer (probably most of them), try ensuring their default printer is NOT a network printer, but say the local PDF printer. (or print to pdf).


So, workstations without a printer.

So, workstations who have default printer = some network printer (don't do this)

(change this to local printer for testing – see if it helps).

So, access reports fixed/set to a printer that does not exist.

So, you need/want to check if any reports have anything “different” then "default" for reports printer.


So far?

My bets are:

You suspections may well be correct – it’s something to do with that windows update.

Or

The default or missing printer(s) issue…….

R
Albert

So the default printer pointing to a non-existent network printer is still a problem? I thought Microsoft had that fixed years ago.

 

[The_Doc_Man]

So, access reports fixed/set to a printer that does not exist.

I wasn't aware that you could set up a printer that wasn't on the network. Windows doesn't like that. If it isn't in the Windows list of available printers, I don't recall that you can just name a printer out of the blue, because Windows can't determine synchronization characteristics for printers that aren't on-line. I recently verified that when I bought my wife a new printer, plugged it in, and forgot to turn it on. Windows absolutely refused to cooperate even though I knew what the name would be. Then I did a face-palm and realized I had skipped a step or six.

 

[RonPaii]

I wasn't aware that you could set up a printer that wasn't on the network. Windows doesn't like that. If it isn't in the Windows list of available printers, I don't recall that you can just name a printer out of the blue, because Windows can't determine synchronization characteristics for printers that aren't on-line. I recently verified that when I bought my wife a new printer, plugged it in, and forgot to turn it on. Windows absolutely refused to cooperate even though I knew what the name would be. Then I did a face-palm and realized I had skipped a step or six.

The only time I saw that problem was on laptops when not connected.

 

[The_Doc_Man]

I'll further qualify my statement... you can't create a new printer if it isn't online, but if your already-installed printer is currently turned off, you can still select it. The REAL barrier is that when you go to print a report, the printer's info has to be available because the report renderer honors the printer abilities and settings. If those settings aren't available, you have a problem.

 

[Albert D. Kallal]

So the default printer pointing to a non-existent network printer is still a problem? I thought Microsoft had that fixed years ago.

No, it can still trip up things. To be fair, in NEAR ALL cases, this is going to trigger that really slow flip into design mode (for any form, or any report -- not just the bad one). So, to be fair, I am suggesting to check this, but in near all cases, such slowdowns are not a accDE or workstation slowing down when using the application, but is a slow-down issue for when developing/designing forms and reports.

However, I have still see a general slow down as a result of above.


As for other comments about non existing printers?

Sure, lots of reasons.

First up, many users on your network might share their printer, of which then you can use and select.

Hence, if any of those computers go to sleep, or remove's that printer, or changes their printer (say they get a new/different) printer)?

Then that printer is gone, and non existing.

Same goes if even a shared server printer - might be replaced.

Or even those network printers that are not even attached to a computer. They can break, or be replaced -- often with a different model/printer.

So, quite a few scenarios in which such printers one has used or chosen in the past?
They can go away.....

R
Albert