Windows update causes VB6 app to fail when fetching data from Microsoft Access

I don't remember exactly how I got Microsoft to help me. I found a Microsoft site for business support

This is a very common phishing scheme used by malicious users to allow them to access your machine and install malware. You should confirm that the site and help you got was actually from an official MS Support provider and not a malicious user. In general I'm not aware of MS providing this service but I've never had a need for it either. I would strongly recommend that you ensure your malware software is running, hasn't been replaced and then do a full scan of your system.

Procmon is overwhelming so do the following.

1. Run Procmon as an admin.
2. On the toolbar at the top right is a list of filters for registry, file system, etc. Uncheck all of them except the file system.

3. Next you want to filter down to just the process that you're running, your VB6 app. Click on the Filter option and in the options dialog select the Process Name filter, the operation as is and the value the name of your executable program. Then click Add to add it.

4. There will still be lots of events so the next step is to try to get the error to stand out. On the Filter menu select Highlight. In the options dialog set the category to Result, the operation to is and the value to FILE NOT FOUND. Then click Add. I believe this should highlight any rows that are generating this error.

5. Finally you'll want to filter out processes that generate lots of messages but are not relevant. In the main list right click extra proocesses and select Exclude xyz.exe to remove them from the list. Some of the more common one's you should filter out are: lsass.exe, explorer.exe, svchost.exe, ctfmon.exe, MsMpEng.exe, csrss.exe, msedgewebview2.exe, services.exe, SearchIndexer.exe, sihost.exe, BackgroundTaskHost.exe, RuntimeBroker.exe, taskhostw.exe, msedge.exe, chrome.exe, dwm.exe, onedrive.exe, SearchHost.exe
6. Now you're ready to find the errors. Click the toolbar button to clear the list so you are starting from scratch. Now run your program and wait for the error to occur. Once it does then go back to Procmon and see if it highlights any rows. Your process should be in that list and hopefully it'll tell you what file it was failing to load.

Followed your instructions, except for step 5. Tons of lines shown, but none highlighted. Any other ideas?

The highlighting may not work so remove it and then filter the list as I suggested and then scan the list manually. It should be a lot smaller now so it is easier to find things. You're looking for where results isn't SUCCESS. As you run across processes that you know aren't applicable then right click and exclude them. This will more quickly narrow down the results to what you need.

If you aren't seeing any file operations list then you might have selected the wrong boxes in the command bar. All file operations will generate log entries here and given your error of not being able to find a file then it should be in there somewhere.

Started PROCMON from scratch again today and set it up per your instructions. I do see several "SHARING VIOLATION" results on CreateFile operations. They all show "Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a" when trying to CreateFile file Common.ldb .

My program reads & writes an Access database that is in the same folder as the program. Inside that database is a linked table which comes from another Access database, Common.mdb, which is in a separate folder. This all worked fine until the recent Microsoft update was applied.

A share violation would seem to indicate that something else already has your Common database open, perhaps Access itself. This could also happen if your application crashes and leaves Access running in the background. This doesn't quite line up with the error you originally posted though...

The .ldb is a lock file that is created by Access to manage access to shared databases. If the file exists before you start your app then something else already has it open. Try to delete the file and then run your app again.

I assume that you had previously enabled multi-user/shared access on the database otherwise it would not create the lock file I believe. I also assume that the actual database sitting in the separate folder isn't on a network share or something that could get in the way.

It turns out that I happened to have the Common database open at the time I ran my last tests. I just closed that and the problem still exists. I'll try the test with Procmon again in a little while.

The Common database is not on a network share, it's on the C: drive of my laptop, where everything is.

I take back part of my previous comment. The Common database is in a folder by itself. My VB6 app exists in another folder. I didn't have the Common database open earlier; I had another version of the VB6 app open. In any case, with neither the other app nor the database open, it still fails.

And in the folder with my Common.mdb, there is no .ldb file.

@Rich Goldberg Process Monitor Version 4.01 uses the string "NAME NOT FOUND" as the error result upon a DLL load failure for a missing library. It may also report using "PATH NOT FOUND" as the system searches for the DLL. Don't include the quotes when specifying a Procmon highlight filter.

For example,

Try using Procmon again highlighting for those results.

Also, according to Error in loading DLL (Error 48) there are other possible causes for this runtime error that will not be reflected as "NAME NOT FOUND" or "PATH NOT FOUND" in Procmon reporting.

There are a bunch of "NAME NOT FOUND" and "PATH NOT FOUND" for dao360.dll . Then one for KERNELBASE.DLL.mui . One for netmsg.dll . One for netmsg.dll.mui . Then six in a row: Two each of C:\Windows\WINHELP.INI, C:\Windows\SYSWOW64.HLP, C:\Windows\Help.HLP .

Question: For half a century I was a software developer at one of the top computer manufacturers in the US. When a customer had an issue, they contacted our support center, and if the support center couldn't solve the problem it was passed to the developers. I appreciate all the help this forum has provided, but I have to ask -- does Microsoft provide any way for me to work with someone from their development group? I've worked with several people from their support staff, none of whom were able to solve this problem....

If you're getting a FnF for dao36.dll then there is something wrong with the DAO 3.6 library which is what your VB6 app is trying to use. I believe you earlier re-registered the DLL so it should be there. But please confirm the DLL is in the path the app is looking for it.

When you re-registered the DLL earlier you might have registered only the 64-bit version, which VB6 won't use. Open a command prompt in 32-bit mode. Unfortunately Windows doesn't provide a start menu icon for that so you will need to do one of the following.

1. Search for Windows Powershell (x86) and run that as an admin. This uses the x86 version of PS and will allow you to register the DLL.
2. Run Command Prompt as an admin and then launch the 32-bit version using %windir%\syswow64\cmd.exe Now you're in an x86 CLI and can register the DLL again.

There are many successful CreateFile for C:\Program Files (x86)\Common Files\Microsoft Shared\DAO\dao360.dll . Then near the end of the trace it tries to do a CreateFile for "C:\Goldberg\KBI\AnH\2025\Program 25a\dao360.dll", which is the folder where my program is. Of course I don't have that dll in that folder, so it gets a "NAME NOT FOUND". Then it tries "C:\Windows\SysWOW64\dao360.dll" and gets the same error. It tries my folder twice more, then C:\Windows\SysWOW64\ again, then C:\Windows\System, then C:\Windows, then repeats a few of those. Then it tries C:\Windows\SysWOW64\wbem, C:\Windows\SysWOW64\WindowsPowerShell\v1.0, and then C:\WINDOWS\SysWOW64\OpenSSH, which gets "Path not found". Then it tries a bunch of folders, starting with C:\Goldberg\KBI\AnH\2025\Program 25a%SystemRoot%\system32\ looking for it. This group all get "Path not found". And then it moves on to a different DLL filename.

That is the standard Windows search functionality. Eventually your app is going to trigger a load library call to load the binary. It'll start in your app's directory and won't find it there. Then it starts walking the PATH variable values until it either finds the file or runs out of paths at which point it'll fail. This is expected behavior. Because you're running an x86 app then it looks in c:\windows\syswow64 for the DAO360.dll because that is where system files reside for x86 apps.

It sounds like the DAO library isn't being found in the path. I would have thought it was using COM to load the binary. Nevertheless there are 2 things to check. First make sure it is registered correctly to COM.

1. Open Registry Editor
2. Search for HKEY_CLASSES_ROOT\TypeLib\{00025E01-0000-0000-C000-000000000046}. This is the type library for DAO. The win32 default value should be the path to the DLL. It uses environment variables and that is OK. If that isn't there then you need to re-register the DLL from the x86 command prompt as mentioned earlier.
3. Next check the COM class which is at HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{00000100-0000-0010-8000-00AA006D2EA4}. This is what your VB6 app should actually be using for the COM call. The inprocserver32 key should have a default value of the path to the DLL as well. Again, if it is wrong then re-register the binary.

If, for some reason, the DLL is being loaded directly then it wouldn't be found because it isn't in the system path. You could technically add the full path to the DLL directory in the PATH variable of the system and restart your computer. This would resolve the load library call but, again, I wouldn't expect your VB6 to be working that way. So I would only do this as a last resort.

A couple more possibilities:

• The DLL has a dependency on another DLL that isn't available. This causes the first DLL to fail to load. But Procmon would show the related DLL not being found either. A quick review of the dependencies shows that DAO only relies on the core COM and system binaries so this seems highly unlikely.
• COM security is messed up. This is a lot harder to diagnose.

In Registry Editor I found HKEY_CLASSES_ROOT\TypeLib{00025E01-0000-0000-C000-000000000046} . It’s got nodes 4.0 (Microsoft DAO 3.51 Object Library) and 5.0 (Microsoft DAO 3.6 Object Library).

 In 4.0 is node 0, which has node win32 with a default value of C:\Program Files (x86)\Common Files\Microsoft Shared\DAO\DAO350.DLL . 4.0 also has a node FLAGS, which has a (Default) value of 0. Node HELPDIR has a (Default) value of C:\Program Files (x86)\Common Files\Microsoft Shared\DAO.

 Node 5.0 has node 0, which has node win32, whose value shows Name=(Default), Type=REG_SZ, Data=(value not set). Node FLAGS shows Name=(Default), Type=REG_SZ, Data=0. Node HELPDIR shows Name=(Default), Type=REG_EXPAND_SZ, Data= %CommonProgramFiles%\Microsoft Shared\DAO\dao360.dll.

If you see anything suspicious in all this, please let me know. Thanks once again.

That seems odd. You should have DAO 3.6 installed, not 3.5. To confirm in the Microsoft Shared\DAO folder the dao360.dll is there and not dao350.dll? It doesn't appear the typelib is properly registered for 3.6. That is what the regsvr command given earlier should do. Can you confirm you ran it under the x86 command prompt and it reported success?

Also confirm the CLSID is properly registered.

In C:\Program Files (x86)\Common Files\Microsoft Shared\DAO there is a DAO350.DLL (dated 4/27/1998) and a dao360.dll (dated 4/1/2024).

 I just successfully ran (again) the regsvr32 via command prompt as an administrator.

 In Registry Editor I found HKEY_CLASSES_ROOT\TypeLib{00025E01-0000-0000-C000-000000000046}. In 4.0\0\win32 the Default value is set to C:\Program Files (x86)\Common Files\Microsoft Shared\DAO\DAO350.DLL . In 5.0\0\win32 the Default value shows “(value not set)”.

Re-ran regsvr32 "C:\Program Files (x86)\Common Files\Microsoft Shared\DAO\dao360.dll" successfully.

HKEY_CLASSES_ROOT\WOW6432Node\CLSID{00000100-0000-0010-8000-00AA006D2EA4} shows (Default) with a value of DAO.DBEngine.36 . InprocServer32 has a (Default) value of %CommonProgramFiles%\Microsoft Shared\DAO\dao360.dll .

Just ran my program again. Still fails.

To be sure, I just changed the name of the old DAO350.DLL file (putting "X" before it), ran the program again, and it still fails.

Can you confirm whether the CLSID key mentioned earlier is present?

In the TypeLib key where the 5.0\win32 node is empty. Set it to the path to the dao360.dll. %CommonProgramFiles%\Microsoft Shared\DAO\dao360.dll

The class key HKEY_CLASSES_ROOT\WOW6432Node\CLSID{00000100-0000-0010-8000-00AA006D2EA4} shows Name=(Default), Type=REG_SZ, Data=DAO.DBEngine.36 .

InprocServer32 for it shows

(Default), type REG_EXPAND_SZ, value %CommonProgramFiles%\Microsoft Shared\DAO\dao360.dll

Assembly, type REG_SZ, value dao, Version=10.0.4504.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

Class, type REG_SZ, value dao.DBEngineClass

RuntimeVersion, type REG_SZ, value v1.0.3705

ThreadingModel, type REG_SZ, value Apartment

I have updated the TypeLib key to %CommonProgramFiles%\Microsoft Shared\DAO\dao360.dll .

 Ran the program. Still fails.

Since you are using VB6 you should probably check the TypeLib under SYSWOW6432Node as well. Make sure the same TypeLib is properly configured there. Note that in my case there are actually 2 TypeLib keys. They look identical to me which means there is likely an invisible character or space in there somewhere. In my case the DAO library is in both subkeys. So ultimately this object is registered 3 different times.

If that still doesn't work then can you provide a minimally reproducible example of your code including the references your VB6 app is using?

I'm sorry. When I search in the Registry Editor for SYSWOW6432 it can't find it.

Currently I'm at a similar name, Computer\HKEY_CLASSES_ROOT\WOW6432Node\TypeLib, but if that's the correct place, I don't see how to configure the TypeLib.

Sorry, yes it is SYSWOW6432Node. The fact you don't have anything there really indicates to me that the x86 DAO isn't registering properly. That would explain all the issues. Assuming you have confirmed you're running the x86 command prompt then regsvr32 should register the COM component correctly.

Just to confirm, do you have Office x86 or Office x64 installed? Specifically I'm wondering if the old JET/ACE database stuff is messed up. Reinstalling that might fix it. But finding it might be hard as it hasn't been shipped since VS 6 as far as I know.

Do you have a minimally reproducible VB6 app that can be tested?

@Rich Goldberg You can use the Sysinternals utility Sigcheck to determine the bitness of dao360.dll. It will show whether it is a 64-bit or 32-bit DLL.

c:\Program Files (x86)\Common Files\Microsoft Shared\DAO\dao360.dll:

    Verified:       Signed

    Signing date:   2:48 PM 9/5/2024

    Publisher:      Microsoft Windows

    Company:        Microsoft Corporation

    Description:    Microsoft DAO 3.6 Object Library

    Product:        Microsoft« Jet

    Prod version:   03.60.9765.0

    File version:   03.60.9765.0

    MachineType:    32-bit

    Binary Version: 3.60.9765.0

    Original Name:  DAO360.DLL

    Internal Name:  DAO360

    Copyright:      ⌐ Microsoft Corporation. All rights reserved.

    Comments:       n/a

    Entropy:        6.206

I just tried to open my VB6 to test something, and it says “Can’t find file ‘DAO350.DLL’ and terminates.

But I had a brainstorm (perhaps)… When this situation occurred the first time, 6 months ago, just like now I was unable to access the data for individuals. But accessing other data worked. So now I think, like Bruce in this forum, that Access is the issue here. Let me explain:

This app supports several non-profits raise funds. It allows individuals to send gifts to families that they choose, and the local organizations make a profit on each transaction. The info about each sender family and each receiver family, such as their name, address, etc.,  is kept in the table NameAddr_Tbl in the Access database. Each family in the table has got a unique Sort_Key and mine, e.g., is “goldberg r”. Another table, P_SR_TBL, contains sender and receiver keys for each transaction, e.g., one line may include Sender as “goldberg r”, Receiver as “columbus c”. For many years both of these tables (and many more) were kept in the same database. The problem was that each organization that I help has its own database on my pc. So org #1 in any particular year had its own database of name/address info and also sender/receiver keys. When addresses (and spouce names, etc.) changed, it was updated in their database. When org #2 began their fundraiser, I would manually copy the NameAddr_Tbl from org #1’s database into org #2’s database, and so on. That process got old after a while. I also link that NameAddr_Tbl into many Excel spreadsheets that need that data. I had to continually remember to relink to the current NameAddr_Tbl. So I had the great idea to move the NameAddr_Tbl to its own database, then link each organization’s database to the standalone NameAddr_Tbl. That way every database and spreadsheet automatically has access to the most current name/address information.

Now, from what I remember when I hit this same issue 6 months ago, my testing always begins with using my app to display a sender or recipient’s information, and this always gets an error. But the app had no problem showing other info from the database. (I can’t test that at the moment due to the DAO350 problem and my not wanting to rerun critical one-time reports. This tells me that VB6 was able to access the primary database, but when I fetched NameAddr_Tbl info from its linked database it fails. That sounds like an Access issue and not VB6.

I believe I saw that a recent Access update tightened security on accessing its data. I'm guessing that's where the problem is currently, trying to use the primary database to fetch data from the secondary (NameAddr_Tbl) database.

And yes, Michael, I do have a minimally reproducible VB6 app that can be tested, if we can work out a way for me to get it to you.

If the error you're getting says it cannot access DAO350.dll then something is wrong because that is the old version of DAO, not DAO360.dll that you've been talking about all along. Mixing the libraries isn't going to work. Please review the references in your project and confirm that you're using DAO 3.6. If so then DAO350 isn't used and shouldn't be loaded. If something is loading that then there is a problem.

If you believe the issue is with the linked database then have you confirmed the permissions on the linked database are correct for the user running your application?

The DAO350 issue occurs only when I open VB6 itself. This didn't happen six months ago when the issue appeared the first time. When I run the compiled app I don't get the DAO350 issue.

I never had issues with the permissions on the linked database until this update, and I don't even know how to check them. I can open the linked database manually with no error.

Open the main database like your app does and then try to query from the linked database's table like your app is doing.

I used Access to open the main database and created the following query to read from the linked database:

SELECT
    NAMEADDR_TBL.Sort_Key,
    NAMEADDR_TBL.LastName
FROM
    NAMEADDR_TBL
WHERE
    (((NAMEADDR_TBL.Sort_Key) = "goldberg r"));

This correctly displayed my linked data.