We are using wwhttp to download a file for our update process. After updating to Windows 10 1803, several of our clients are receiving error 12007: The server name could not be resolved and the file is not downloaded. The application is using an httpget with the url: http://liveupdate.blackmountainsoftware.com/updates/spy1zzip.exe. I'm understanding the error 12007 is coming from wininet.

So far, the only way to resolve is to roll back Windows 10 Update 1803. It doesn't seem to effect all of our clients or anyone in our office.

Anyone else come across this or have any suggestions?

Thanks, Chad Newman Black Mountain Software

I'm running 1803 and I can access your url fine.

The Windows error is:

12007: The server name or address could not be resolved

which seems to point at some sort of network routing, proxy or DNS problem.

Make sure you have a reasonably recent version of the Client tools. Really old versions (pre-5.0 at least maybe even up to 5.5) had defualt proxy settings that can cause problems under certain network situations.

Either way that download is likely to fail if you download to string, because the file is too large to download into a string. Make sure you download directly to file using the file parameter.

+++ Rick ---

Rick, Thanks much for your response. We have since found others who are experiencing this issue where there applications that use the internet to process information are no longer working either.

https://blog.mertech.com/windows-10-version-1803-breaks-some-shared-folder-applications

Looks like if the application is running from Windows Server 2003 (smb 1.0) with Windows 10 1803 there is an issue. Windows Server 2008 or newer are not effected. We are running Windows 2012 and 2016 and we don't have the issue.

Windows Defender and Symantec AV seem to be a part of the cause as replacing them with a different AV resolves the issue (we use eset in our office).

Thanks again,

Chad Newman Black Mountain Software

Thanks for the link--that was very helpful. We've got a Visual FoxPro 9 SP2 application for which we often turn off SMB2/SMB3/op-locks and enable SMB1 to prevent table and index corruption. After the Windows 10 1803 update, the application could no longer make connections to the Internet using wwHttp. One specific way in which we use this is to fetch data from payment gateways that we integrate with (Authorize.net, USA Epay, etc.) and compare that to the payments that we have stored in the application database.

The way I worked around the problem was to create a launcher EXE that we install on the local workstation, which then launches the regular application EXE that resides on the SMB1 network share. This seems to fool Windows into thinking it's a local process since it gets spawned by a local process.

If your VFP applications are installed locally or you're using SMB2/3, you shouldn't be affected. But for anyone using SMB1 and installing/launching your app from an SMB1 share, you may find that some features suddenly no longer work after this Windows update.

I suspect this is just MS incrementally "tightening the noose" on SMB1 until they eventually disable it completely.