Windows 10 May Update Problem

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

Hi.

We got (perhaps) the same problem. If I wrongly understand sorry.
We start from this post:
stackoverflow.com/.../after-windows-10-update-1803-my-program-cant-open-a-socket-when-running-from-ne
to arrive to the real problem: we use AcuThin from a network share folder ... using smb1.

We tried to disable smb v1 and enable smb v2 (regedit, control panel, etc. google this) .... Now we have some installation where the problem is solved and other where it isn't.

I hope this can put you on the right track.

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

Same problem should involve COBOL program running on wrun32.exe on shared smb 1 folder: they couldn't open socket (c$socket)

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

What version of the runtime are people using? Is this:
- specific to a runtime version
- specific to AcuShare only
- or will it affect all users on Win10 PC running on mapped smb1 drive?

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

Not sure you can switch to smbv2 ... it doesn't support opportunistic locking, which I think causes problems with acu. Before making that change, I recommend you do thorough testing, with multiple users. We experience a lot of file IO contention errors.

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

Oh :-(

Thank you for yours suggestion.

We will have to plan a lot of test !!!
--
Davide Giudici

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

Thanks to all for the replies. We are running Runtime version 10.0.0 32-bit on these machines. I guess my only question is that we are getting this same problem on servers running 2003 (granted they would be SMBv1), 2008-R2 and 2016. It would seem that the newer servers would be running a newer version of SMB and would not have the same problem as starting up the wrun32.exe off an SMBv1 share which I will say we are starting up all wrun32.exe processes from the server share just to simplify installation and upgrade issues with runtimes on all machines versus just putting it on the server and sharing it out from there. But seems like it might be worth a try to install on a PC experiencing this issue and see if it can then talk over C$SOCKET.

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

Hi dalekreitzer,

I'm in doubt with your suggestion.
In the past we got in trouble caused by opportunistic locking, so we DISABLED it in our installations.

Now I found that:
“You cannot turn off opportunistic locking for SMB2” (support.microsoft.com/.../configuring-opportunistic-locking-in-windows)

So it seems to be the opposite of your sentence: "it doesn't support opportunistic locking"

--
Davide Giudici

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

Hi,
I'm not entirely sure about your specific problem, but just to say, SMBv1 is now turned off in Windows 10 and has been for a while due to major security concerns in the protocol.

support.microsoft.com/.../smbv1-is-not-installed-by-default-in-windows

There's information about oplock settings on there:

"You can specify a share without using oplocks or leasing to allow a legacy application to work with SMBv2 or a later version. To do this, use the New-SmbShare or Set-SmbShare PowerShell cmdlets together with the -LeasingMode None parameter."

Obviously I don't know your specific situation, but I'd recommend that you stop using SMB1 if you are able, see: blogs.technet.microsoft.com/.../ for more information.

Thanks,
Nick

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

Hi Nick.

After another hour spent online, I guess you're right about SMBv2 configuration.

Thank you ! ! !
--
Davide Giudici

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

You are right ... I had it backward. My point, though, was using SMBv2 in some cases doesn't work with Acu. Making this change should be done with care.

Is anyone else seeing problems caused by Windows 10 PC's installing the latest (May 8, 2018) updates? We have multiple sites reporting issues with multiple PC's after installing the May 8th updates. Specifically they are unable to communicate with AcuServer (we use the default port 6523). They are also unable to use a few programs included in our application software that communicate with corresponding programs on the server using the C$SOCKET library routine included in AcuCobol. One client first reported it on one Windows 10 PC that updated, then two days later, same problem on another PC, and now a 3rd PC. Another client reported all 3 of his Windows 10 PC's updated on Friday and then these were no longer able to use C$SOCKET to "talk" to the server starting Monday. Another client using AcuServer for their data file traffic reported their Windows 10 PC updated last week and was immediately unable to use our application due to 9D errors on data files. Once we pointed this PC to a different runtime config file using all mapped drives to bypass AcuServer, the PC is able to work and access data over the mapped drive, but then this PC gets an error when using a program that uses the C$SOCKET routine like my other clients that do not use AcuServer and use only mapped drive for data access. We have tried checking for firewalls on these PC's, antivirus, trusting the wrun32.exe in AV, etc. with no luck. The server version does not seem to matter as we are seeing this with Windows Server 2003, 2008-R2 and 2016 all as servers. The common trait seems to be the recent Windows 10 updates. We do put the AcuServer port # and our own port # in server firewalls for Windows Server versions that include a firewall. We have not had any complaints from Windows 7 users on this particular issue. It really seems like something is blocking or has broken this type of communications. Thanks for any input or feedback anyone has to offer!

Here is all the info on the cause of this issue along with all known workarounds and news from Microsoft on an upcoming fix:

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

OLIVER

Sign up

Please log in or register:

Welcome to the Rocket Forum!

Please log in or register:

Scanning file for viruses.

This file cannot be downloaded