windows-itpro-docs 🚀 - Microsoft Access Database corruption

Please submit this request via the Feedback Hub (see https://docs.microsoft.com/en-us/windows/deployment/upgrade/submit-errors). Thank you!

andreabichsel on 18 May 2018

Andrea, we too have several customers experiencing this same issue. Is there a resolution? Do we know what changes in 1803 are causing the issue?

russcummings on 23 May 2018

👍1

The best way to get support on this issue is through the Feedback Hub (see https://docs.microsoft.com/en-us/windows/deployment/upgrade/submit-errors). Thank you!

andreabichsel on 23 May 2018

Same problem like Kevin-Meers.
Andrea, sorry but we can't enter in "Feedback Hub" and do the job of beta testers.
I suspect it may be related with SMB protocol changes in this Windows compilation (timeouts or something...)
Update 1803 caused a lot of problems that have affected windows users, and the corruption of Access Database is one more.
Please inform about news.
Thanks.
[email protected]

bbartres on 8 Jun 2018

For my scenario and many days and hours investigating this issue, the Windows 7 workstations had no issues accessing and sharing the network mapped backend database. The backend database became corrupted as the Windows 10 (1803) workstations were introduced into the database and performed extensive query and table operations. Evidently SMB changes are the culprit in the 1803 update and the following fix (and workstation reboot) worked for me which was applied to all the Windows 10 (1803) workstations in this environment. Copy and save the following text to notepad and save it as "SMBCacheFix.reg" (with quotes)

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetServices\LanmanWorkstation\Parameters]
"FileInfoCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
"DirectoryCacheLifetime"=dword:00000000

You may also review the "DisableLeasing" registry settings for Windows Server 2012 or above pertaining to the server side if the fix above does not resolve your problem.

ITYIPMan on 22 Jun 2018

👍3

Exactly what I've been experiencing on my system. database becomes corrupted and unstable. it's not the kind of corruption when there's a bad write. it's unstable due to open handles , due to network interruption.

ITYIPMan, (with Adam) we applied the SMBCacheFix.reg to the windows 10 machines and so far, it seems to be working. If I experience a crash today, I'm rolling back the windows 10 to 1709. This has produced a lot of "unsettled" managers!

Fenious on 25 Jun 2018

I got some feedback on the problem, their suggestion was changing the services from manual to automatic delayed start). I think your solution is the more accurate. so, when I go to add the dword string value, options are 32 or 64. Does that matter? The application is running on access 2003, but on both 32 and 64bit systems.

the test line I have:
FileInfoCacheLifetime REG_DWORD 0x00000000 (0)

Does that have correct values?

TomDooher on 3 Jul 2018

DWords registry keys are 32bit. All the systems that I've worked on are 64bit OS utilizing MSOffice 32bit applications. The registry settings above will work as they are but they need to be applied as a group of the 3 values as listed since they all interrelate to each other regarding the Windows OS network communication settings (not the MSOffice application). I did not apply this to the Windows 7 64bit machines but only the to the Windows 10 64bit OS which are all running the 1803 update. It's been just about 2 weeks with very stable operation and no database corruptions.

ITYIPMan on 3 Jul 2018

Brilliant! I will be testing this locally and then applying to the customers having the issue.

Thanks!

Tom Dooher

Amcom Software

From: ITYIPMan notifications@github.com
Sent: Tuesday, July 3, 2018 9:18 AM
To: MicrosoftDocs/windows-itpro-docs
Cc: Tom Dooher; Comment
Subject: Re: [MicrosoftDocs/windows-itpro-docs] Microsoft Access Database corruption (#934)

DWords registry keys are 32bit. All the systems that I've worked on are 64bit OS utilizing MSOffice 32bit applications. The registry settings above will work as they are but they need to be applied as a group of the 3 values as listed since they all interrelate to each other regarding the Windows OS network communication settings (not the MSOffice application). I did not apply this to the Windows 7 64bit machines but only the to the Windows 10 64bit OS which are all running the 1803 update. It's been just about 2 weeks with very stable operation and no database corruptions.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/MicrosoftDocs/windows-itpro-docs/issues/934#issuecomment-402213529, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Am6TGjT7fHGOPA3eRXKGbncfz3ybDuLjks5uC5lYgaJpZM4UE4zo.

TomDooher on 3 Jul 2018

Feedback...
It's now nearly two weeks since the problem. Accessfix1803.reg from ITYIPMan worked. yes. all three values were applied (just ran the .reg) So far, so good. not a single network interruption since.
And, yes, applied to just the Windows 10 1803 machines. I think they are all 64 bit.

Fenious on 3 Jul 2018

Having this same issues with lots of Windows 10 PCs. Hopefully the @ITYIPMan registry fix will work (thank you).

Here is the @ITYIPMan registry file changes in zip format for easy download and install:
http://soft.cambus.com/scripts/SMBCacheFix3.zip
(please be very careful downloading registry mergers from the internet. this is provided as-is and incorporates the exact code seen above. please review the changes in notepad before merging)

Screenshot of before and after effects on the registry:
http://soft.cambus.com/scripts/smbfix-moreinfo.html

Please remember to reboot workstation after registry merge.

camtera on 22 Dec 2018

Just a follow-up for Spring 2019... It appears that newer Windows 10 feature updates (1809 and soon 1903) are being pushed out from Microsoft. With this in mind, it is unknown if these SMB settings will be reverted to their original settings. Attached is a "Check SMB Settings" batch script that can be run on each pc or from a network server to check the status of the applied registry settings. If settings need to be reapplied, use the SMBCacheFix3.zip link above to apply the SMB settings again. (Note: Please be very careful downloading scripts or registry settings from the internet. This is provided as-is and incorporates the read only query code to view the registry settings. Please review all scripts in notepad before executing any code.)

Check SMB Settings.zip

ITYIPMan on 3 Mar 2019

My machines are Windows 10 release 1809. What's the status on this registry fix? I don't see the FileInfoCacheLifetime, FileNotFoundCacheLifetime and DirectoryCacheLifetime keys. Was this issue fixed? Or do I need to manually create these registry keys?

alexmuch on 9 Apr 2019

By default, Windows 10 will not have these registry settings applied and will have to be applied manually or through a GPO. Some of our Windows 10 machines recently updated to 1809 from the 1803 version. The registry settings have remained intact after this upgrade. I personally have not tested 1809 without the registry settings since it was such an issue last April for the customers that I support. Personally, If its a new computer with 1809 and you are going to share a MSAccess database on the network, I would import the registry settings and reboot the Windows 10 computer. I haven't had any issues with the registry settings applied. The script that I posted above (Mar 3) allows you to easily "check" to see if the registry settings are applied.

ITYIPMan on 9 Apr 2019

Instead of my suggested fix above from Dec 22, 2018, we've found this registry tweak to work the best
http://soft.cambus.com/scripts/disableleasing-moreinfo.html

If you are seeing performance issues, I suggest using this approach ("DisableLeasing" entry), and remove the SMB fix. According to users in the below thread, there have been performance issues with smb fix although I never encountered them.

For more info, search 'performance' on this thread:
https://www.devhut.net/2018/06/13/access-bug-database-is-in-an-unrecognized-format/

camtera on 9 Apr 2019

Sorry, a couple more questions. How can I verify that my .mdb is in fact corrupted? I'm running into an "unrecognized format" error but I can still open my .mdb's in MS Access with valid data appearing. Does this mean my db's are not actually corrupt?

Also, is this fix exclusively for networked databases? My databases are created and used locally.

alexmuch on 9 Apr 2019

It is difficult for anyone else to know if your DB is corrupt without being able to analyze it in person. The warning or error message is indication that something is not as good as it should be, so you should try to export your data to a new DB to test that all of your data is still valid for future use. Better safe than sorry, you know.

illfated on 9 Apr 2019

FWIW, Before the aforementioned fixes above, Access would indicate the database was corrupt and would always successfully repair. We never had to create a new DB and import tables from the corrupted DB.

camtera on 9 Apr 2019

👍3

I have read that some people have moved the backend access mdb/accdb to Synolgy NAS with success. Has anyone here tried that?

ZenMasta on 16 Apr 2019

Please post discussions on more appropriate Microsoft Support forum pages.
This Github issue tracker is primarily aimed at improving the documentation pages.
Only post here if you have got constructive improvement suggestions for the page
https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-1803-removed-features .

illfated on 16 Apr 2019

By default, Windows 10 will not have these registry settings applied and will have to be applied manually or through a GPO. Some of our Windows 10 machines recently updated to 1809 from the 1803 version. The registry settings have remained intact after this upgrade. I personally have not tested 1809 without the registry settings since it was such an issue last April for the customers that I support. Personally, If its a new computer with 1809 and you are going to share a MSAccess database on the network, I would import the registry settings and reboot the Windows 10 computer. I haven't had any issues with the registry settings applied. The script that I posted above (Mar 3) allows you to easily "check" to see if the registry settings are applied.

I just got the Access Corruption Errors again today! We installed 1809 a few weeks ago with no issue until now. My fix back in Aug 2018 was to add the Disableleasing reg entry on the Win 10 server, no workstation updates and that worked great. I just checked the server registry and that entry is missing! I put it back and will see how it goes tomorrow. I am assuming the server reg change, getting rid of the entry, was made with the 1809 install, and it took 2 weeks to show up as an error??

mikedmd on 9 May 2019

Hey everyone, I found the problem that was causing my "unrecognized database format" error. There was a KB released in January 2019 that caused this problem for '97 format Access databases that have fields containing >32 characters. A KB in February 2019 fixed this issue. For more information, look here

https://answers.microsoft.com/en-us/windows/forum/all/kb4480116-and-kb4480970-failure-getting-access-to/d701b681-2491-4891-baf6-e3a25b5d2bb7?page=3

alexmuch on 9 May 2019

👍1

For my scenario and many days and hours investigating this issue, the Windows 7 workstations had no issues accessing and sharing the network mapped backend database. The backend database became corrupted as the Windows 10 (1803) workstations were introduced into the database and performed extensive query and table operations. Evidently SMB changes are the culprit in the 1803 update and the following fix (and workstation reboot) worked for me which was applied to all the Windows 10 (1803) workstations in this environment. Copy and save the following text to notepad and save it as "SMBCacheFix.reg" (with quotes)

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSetServices\LanmanWorkstation\Parameters]
"FileInfoCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
"DirectoryCacheLifetime"=dword:00000000

You may also review the "DisableLeasing" registry settings for Windows Server 2012 or above pertaining to the server side if the fix above does not resolve your problem.

We are experiencing the exact issue with users of Windows 10 computers who are unable to reliably use a Microsoft Access database via a shared drive. Within a few minutes to an hour of using the database, they receive a "1SQLSTATE: 42S02 Message: [Microsoft][ODBC Microsoft Access Driver] The Microsoft Jet database engine cannot find the input table or query ''.

Unfortunately, the organization still has Windows 7 computers in use. Those computers don't experience any problems.

We have applied the registry changes as described previously and the issue persists. The network drive being used is mapped via a Group Policy with a typical UNC path name \\. We discovered that if we disable the group policy and map the drive via IP address through a login script or manually (net use X: \ server name \ share name), the database remains stable.

We have not performed a packet capture to see if there are any clues at the packet level. We did try adding an entry to the local host file to eliminate name resolution issues. We also disabled IPv6. Nothing seems to make a difference until we map the drive by IP address.

Anyone experience something similar and know what the underlying cause could be?

dacarguy on 19 Feb 2021

Check out https://docs.microsoft.com/en-us/office/troubleshoot/access/your-network-access-was-interrupted-error#symptoms

KevinMeers on 20 Feb 2021

👍1

Check out https://docs.microsoft.com/en-us/office/troubleshoot/access/your-network-access-was-interrupted-error#symptoms

Thanks for the tip - testing now. That makes a lot of sense.

dacarguy on 20 Feb 2021

Windows-itpro-docs: Microsoft Access Database corruption

Document Details

Most helpful comment

All 25 comments

Related issues