Hi,
One PC at a customer that have 60+ is producing this error when trying to make an api call to a postcode lookup site (using XCALL ATHTTP OR XCALL HTTP)



Quotes from the customer in response to our suggestions:

"I’ve fully uninstalled everything to do with Madics then reinstalled it with the latest version and this still fails.

PC is identical to another machine with AV, OS, updates etc yet that other machine loads the search results as intended. I’ve attempted a different login and different user as well so its definitely to do with the software."

"Both dlls exist in the locations you’ve given."

"I’ve also reinstalled 3 times now – rebooting after each uninstall, clearing any ATE related files and folders then reinstalling from the latest version .exe"

"If it was the Webroot AV it would also affect every other machine as the settings are the same across the board. However, I’ve excluded this location entirely and it still fails to register and/or load. I’ve also then disabled AV and reinstalled madics and it still fails. I’ve ran an sfc /scannow which fixed some corruptions but still receiving the same error."

Not sure what else to tell them.

There shouldn't be much to the operation of loading the ashnet.dll other than finding it. And the first place it will look is the location where the ashw32.exe is loaded from. So, assuming that the file really is there (and it certainly sounds like it is), and given that the problem doesn't occur on any of the other 59 presumably similar ATE workstations at the site, we are probably dealing with something mysterious. Before we throw our hands up there are a few possible workarounds we can try:

1. Make a copy of ashnet.dll in the %ATE%\Permcache directory. (It will look there if it fails to load it from the bin directory.)

2. Make a copy of ashnet.dll in the CSIDL_PROGRAM_FILES directory, typically C:\Program Files (x86). (It will look there if it fails to load from the bin or %ATE%\Permcache directory).

I'm not sure why we should expect that it would work better to load the DLL from one of these other directories, but I guess there is a remote possibility that somehow the bin directory is getting tagged by the AV in a way specific to this PC. (If it's really the DLL itself that the AV doesn't like, obviously it won't help to move it, but it would be hard to explain why the AV doesn't then complain for the other users.)

3. If no joy with either of the above, perhaps this is just the motivation you need to take advantage of the fact that for awhile now, HTTP.SBR has been supported directly on the Linux side. It's faster, cleaner, simpler to call it directly, rather than to use the ATHTTP redirect mechanism (which involves passing instructions to ATE to perform the operation and then send the results back.) And the only change needed to the program should be to change ATHTTP to HTTP. Note that it does rely on the dynamic library libashnet.so.1 being linked to the actual libashnet.so.x.x.x that is normally in the bin directory along with the ashell executable (on the Linux side).

Thanks for the location suggestions.

We use AHTTP because a lot of the time, we and the customer don't want to worry about internet access being available for the server all the time, especially as we have old versions of the OSes out there that probably shouldn't have access.

If nothing else, we give you options!

We found the problem using Procmon.exe

The file that was failing was in fact VCRUNTIME140.DLL. That is used to load ashnet and so that then failed.

It wasn't on the PC at all and I think the problem is down to the emergency builds we asked you to do to get the /s working for System Center. It seems to be installing the VC++ 2013 runtime instead of the 2015 runtime. I expect previous builds had the right version so that is why they only have this PC with a problem (it is a new install of Windows although not a new PC). Or they all have the 2015 runtime for unrelated reasons and it is the linking that is "wrong".

We downloaded the VC++ 2015 x86 runtime, installed it and the errors all went away without even having to close ATE

That actually makes sense. I may have falsely assumed that the absence of the necessary VC runtime support would always generate an intelligible error message. (That certainly is the case with executables and static-linked DLLs, but apparently not with dynamically loaded DLLs.)

These VC runtime modules are really an annoyance - I wish Microsoft would see fit to just including them in Windows and updating them as needed, so that every single VC-based application doesn't have to bundle all of the (huge) VC runtime installers with the application installer, just to handle cases like this. In this particular situation, arguably we should just upgrade the ASHNET.DLL to use the same runtime as the ASHW32.EXE executable, but in general, applications (including A-Shell) may dynamically load many DLLs (including ones supplied by third parties) that are shared with other executables, making it impractical if not impossible to keep them all at the same runtime support level. (What exactly is the benefit of being able to load DLLs dynamically if they all have to have been compiled with the same version of the VC compiler? That would be like saying you had to either install A-Shell 6.4 in addition to 6.5 just to be able to run SBXs originally compiled under 6.4; or requiring that every SBX be recompiled when you upgrade A-Shell versions!?)

I'm not really sure what the optimum solution is. But probably at the very least we should include some kind of mechanism to detect when the failure to load a DLL is due to the missing VC runtime. And/or add to the standard tech support toolbox (along with "have you tried resetting?") a link to an all-in-one VC runtime installer.

Microsoft would say just use .NET Never have any compatibility issues with that!

Right! (Sarcasm aside, at least with .NET they do treat it more as a core OS module to be updated on general principles along with other parts of the OS, as opposed to something the applications are responsible for.)