After upgrading to Windows 10 1803 (April Update), users began to complain that they can’t run executable files that are located in network shared folders on the Windows file server and NAS storage.
The problem manifests itself in different ways. Some network applications simply do not start from network folders (The application was unable to start correctly (0xc00000ba), 0xC0000005: Access violation reading location 0x0000000000000000), while others start fine, but all the functionality associated with network connections with other servers is not available. In particular, doesn’t working the connection to the remote MS SQL Server via both ODBC and ADO SQL connection, the client also can’t connect to the Oracle database either.
The problem occurs when you try to run EXE files from shared folders using the UNC path (\\file-server\share\app1.exe) or when you run executables from network folders mapped to a local drive letter (using NET USE).
However, in Windows 10 1709 and Windows Server 2016, the same programs run from network folders correctly. To run these programs on Windows 10 1803, you will have to copy the executable files to a local disk. If you rollback the Windows 10 1803 update on your computer, the problem also disappears.
It seems that Windows 10 1803 blocks network access to programs running from shared network folders and the programs themselves are crash when they trying to open a network socket. The problem is somewhat similar to the problem of disabling insecure guest logons in Windows 10 1709, but this solution did not help.
One of the users found the following workaround: if you select in the exe file properties, that this program should be run in compatibility mode for Windows 8, the network programs start working!
However, as a permanent solution to use it incorrectly. I would like to find the cause of the problem.
During troubleshooting the problem, it was found that in all cases devices supporting only SMBv1 file access protocol were used to provide shared folders service. At the same time, on the Windows 10 workstations a separate client feature was enabled to access network folders using SMBv1 (SMB 1.0/CIFS Client).
If you move the executable files to the shared folder on Windows Server 2012 R2 / 2016, on which SMB1 is disabled, the executable files run correctly!
It can be concluded that Windows 10 update 1803 for security reasons does not allow you to open network connections in programs running from shared folders that are accessible only using the SMBv1 protocol. As network folders, you need to use devices that support SMBv2 or SMBv3.
Get-SmbConnection cmdlet. 
Check if SMBv2 or SMBv3 is enabled on your server with the command:
Get-SmbServerConfiguration | Select EnableSMB2Protocol
If SMBv2 is disabled, you can enable it:
Set-SmbServerConfiguration -EnableSMB2Protocol $true
In our case, the used NAS storage device also supports file sharing only using the SMBv1 protocol, so it can’t be used to run programs on workstations updated to Windows 10 1803.
If you are still using Windows Server 2003 as a file server, you should understand that only SMBv1 is supported in this version. Accordingly, you can’t use this OS as a file server when accessing it from Windows 10 1803 and higher.
Also, if you use Linux Samba as a file server, to disable SMB1 you need in the configuration file smb.conf to add the line min protocol = SMB2 in the [global] section and restart Samba.
19 comments
Thanks for the info! But the problem with running applications from network folders is actually related to updating the engine of the built-in antivirus Windows Defender in Windows 10 1803. If you disable Windows Defender and install an alternative antivirus, the problem with executing executable files from the shared folders disappears. So, if you have a file server with Windows Server 2003 / Windows XP / or an outdated NAS device left on the network, disabling Windows Defender can help you.
My experience is not consistent with the problem being Windows Defender MKGEEK. I get different results when the network location is my NAS (problem evident), compared to a file share on my Windows File servers (problem not evident). And disabling Defender didn’t help at all.
So for me, the problem seems very much consistent with the article.
I also had the same problem with running exe files from the NAS. But at me instead of Windows Defender in my Windows 10 1803 the antivirus Symantec is installed.
The problem was solved by removing Symantec and installing instead a free AVG
The problem is not with Windows Defender. I have Nod32 Smart AV with Firewall enabled(so Windows defender DISABLED) and the problem persist. It´s like ALAN GRESHAM said.
Diego.
It’s a problem with Defender and other Antivirus programs. I uninstalled our Symantec Endpoint Protection Small Business Edition, then enabled the Windows Firewall and install Avast antivirus and the program would load as before. So, I think it’s a Microsoft problem along with SOME of the other Antivirus programs.
So the question is what Avast and AVG modified in the registry to make it work again?
As an additional bit of information on this. I have this issue – but, only on my stations joined in a WorkGroup. The ones using a Domain login can launch and run apps without Databese connection errors.
With the Workgroup apps, I use a specific Username/Pwd to connect to the database. I can open a UDL file and connect successfully to the database. Running the App on the local station works as advertised.
I will be attempting the Avast solution.
[…] The answer is found here. […]
Any new news from MS about a better fix for this rather than a bad workaround?
They broadcast for years that SMBv1 support was going to be dropped – if your network storage doesn’t support (or the case of a NAS device have a firmware upgrade that will support) SMBv2 or SMBv3 then that device has reached the end of it’s useful life for use within a Windows environment. They aren’t going to reverse this…
Yes we already know regarding that SMBv1 support since it was announced! The question is why it will work when you install like AVG and Avast?
Because they aren’t doing as good a job of protecting you against the risks of letting executables hosted on an SMBv1 disk do whatever they like. Or am I missing something?
There must be something change in windows registry or what ever settings, because in windows 1709 it still works, It seems windows 10 1803 is blocking programs that opening a network socket. But anyway as what I saw on MS forum it seems MS is already inform about it and most of the people there are waiting for the subsequent update from MS.
This blog entry from an MSFT is why I don’t think that it’s an accident that we are seeing this behaviour, and why I don’t expect to see a fix from Microsoft.
https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/
A user on MS forum has discovered how AVG fixes the issue. Apparently it’s related to a File System Filter Driver which is part of AVG antivirus applications and when i search about that file the description is “AVG Virtualization Driver”.
But even more encouraging is that Microsoft has now acknowledged that a fix is currently in the works.
https://support.microsoft.com/en-nz/help/4284835/windows-10-update-kb4284835
Many thanks for the info, great work!
This appears to be fixed in KB4284848 released today.
Addresses an issue where some users may receive an error when accessing files or running programs from a shared folder using the SMBv1 protocol. The error is “An invalid argument was supplied”.
Yes, this KB4284848 is the real deal… Case Solve….:-)
Confirmed KB4284848 on win 10 home 1803 allows exe’s to access internet resources when run from a mapped drive using SMB 1.5.