I'm getting a bunch of new work for my Windows hosts but they are all failing with Error while computing. Here is a sample stderr log.

https://www.gpugrid.net/result.php?resultid=32640734

It's happening on both the cuda101 and 1121 types.

You're getting error code 0xc0000135, which officially means 'status_dll_not_found'.

So, you're missing an essential system component. The internet will tell you that you need to re-install the 'dot Net' libraries, but that's wrong in this case: the GPUGrid application ('acemd3') won't - at least, shouldn't - use dot net.

We really need to find the name of the DLL that's missing, and find out whether it's just missing from your system, or a wider problem. It might be a driver problem, or it might be something needed by acemd3 itself.

If and when one of my Windows machines manages to catch one of these new applications, I can investigate further. There's a tool called dependency walker which can show you what's needed but missing, but it's a bit tecchie and requires experience to use it.

If anyone else has this problem, please chip in with whatever information you can find - especially the name of the missing DLL.

My first successful WU from this particular batch:

https://www.gpugrid.net/result.php?resultid=32640974

Output file 09 is very large, over 472 megs.

My first successful WU from this particular batch:

Watching at Hosts Ranking page, many other windows hosts are starting to succeed their tasks, and are quickly ascending in rank.
Nice to see that Windows hosts are recovered to contribute to the Project along with Linux ones!

Output file 09 is very large, over 472 megs.

Just to remember that if some file happened to exceed a 512 MB size, it would become stalled when uploading to server.
Ian&Steve C. mentioned it and was discussed at can't upload results. file size too big being blocked? thread.
I experienced this same problem in one of my hosts, Message #57194.

The file size limit is set on the server, but implemented by the client on your own machine. It's possible to inspect the current value in client_state.xml, and even change it if you catch it soon enough.

But the ultimate fix would have to be made by the project, so it's worth reporting if you see this error happening again.

I'm getting a bunch of new work for my Windows hosts but they are all failing with Error while computing. Here is a sample stderr log.

Sometimes, resetting Gpugrid Project at BOINC Manager may help, given that all app related files will be reloaded.

I'm getting a bunch of new work for my Windows hosts but they are all failing with Error while computing. Here is a sample stderr log.

Sometimes, resetting Gpugrid Project at BOINC Manager may help, given that all app related files will be reloaded.

Perhaps worth a try, but I think it's unlikely to help with this one. Another tried-and-tested solution to some rare problems is to perform a full system restart.

Another WU is done:

https://www.gpugrid.net/result.php?resultid=32640779

And with no more WUs available, it's back to folding.

I have had three tasks complete successfully. They all ran on Quadro RTX 4000 GPU's. Is it possible that only RTX series cards will work?

Everything else is mostly GTX 1080 series but there are a couple Quadro P6000's and Titan Xp's.

These all have driver version 471.11 which is fairly recent but I haven't checked for the latest.

The systems are all Windows based of one flavor or another depending on if it's a server or workstation.

I have completed two tasks so far, one on a RTX 2080 and another on a GTX 1080 Ti.
Two more completed successfully AFAIK and are uploading now.
Same cards.

Can anyone tell whether these new tasks run on Ampere cards, too?

Can anyone tell whether these new tasks run on Ampere cards, too?

Yes, they run fine on Ampere cards also.

Can anyone tell whether these new tasks run on Ampere cards, too?

Yes, they run fine on Ampere cards also.

Thanks, Keith, for the valuable information.
Just to make sure: you talk about Windows, too, or just Linux?

Can anyone tell whether these new tasks run on Ampere cards, too?

Yes, they run fine on Ampere cards also.

In both Windows and Linux systems with updated drivers, at last.

I found one task that failed and the acemd3 application had crashed.

The appcrash is in vcruntime140_1.dll with code c0000135

This server was running Win server 2012 so that could be clue.

I remember awhile back I had problems with another GPU app and I had to update the Visual C++ Redistributable.

I'll keep checking to see if I can find what will get this to work.

I remember awhile back I had problems with another GPU app and I had to update the Visual C++ Redistributable.

I had this happen with Folding@Home, several weeks ago. Maybe you are talking about the same project anyway :-)

I've now got a Windows v218, flavour cuda101, running and saved for posterity.

This is the DLL show of the task actually running (from Process Explorer) - the list of system DLLs is too long to show in this format, but I can look them up.

I think the problem is due to older Windows OS versions that don't have the newer Microsoft Visual C++ 2015-2019 Redistributable. The new ACEMD app seems to require this to work.

If you are running a newer OS and have at least a minimum version of the Microsoft Visual C++ 2015-2019 Redistributable, GPUGRID should work.

If you don't have it you can download and install the latest version from here: https://support.microsoft.com/en-us/topic/the-latest-supported-visual-c-downloads-2647da03-1eea-4433-9aff-95f26a218cc0

I always install both the x86 and x64 versions as I don't know what GPUGRID really needs.

There isn't much work available at the moment to fully test this, but I do have a couple WU running that should finish tonight or tomorrow.

I think the other GPU program I had trouble with a few years ago was Einstein @ home.

Well, as you can see from my screenshot yesterday (which was taken on a machine running Windows 7, BTW), acemd3 has loaded vcruntime140 from the BOINC slot directory - i.e., from an image circulated by the project via its various downloads. That file is actually v14.28.29325.2, dated Fri Sep 25 2020.

Further down the list, it has also loaded vcruntime140_1 from my Windows\System32 directory. That file is v14.25.28508.3, dated Wed Jan 8 2020. Both files are 64-bit images, which is right for my system.

Dependency Walker also finds a requirement for both versions of vcruntime140.

But inspecting the acemd3.exe application with a hex editor, there's only vcruntime140.dll, at offset 000B5A78: no sign of the _1 version.

Looking around Microsoft, I think VCruntime140.dll is the VS2015 version, and VCruntime140_1.dll is the VS2017 version. It rather looks as if the final acemd3 package was linked together from components compiled with two different generations of Visual Studio.

That suggests that jjch's solution in the previous post is the best one - if you encounter any problems in vcruntimeXXX with this project, install the combined redistributable for Visual Studio 2015, 2017 and 2019 from the link in his post.

Well, welcome to DLL Hell (yes, that's a thing).

Looked at my full task list, and found that another machine had a failed task with, you guessed it, error 0xc0000135. The two machines arrived here as exact twins, but diverged over the years as I upgraded bits, used them for different tasks, and so on.

Checked C:\Windows\System32, and sure enough no sign of vcruntime140_1.dll. Downloaded the redistributables package - it's hiding right at the botton of the VS2019 page, in the 'Other Tools, Frameworks, and Redistributables' drop-down list - ran it, and 140_1 appeared.

We've got to wait for another spin of the task-issue lottery wheel to be certain, but that increasingly looks like the explanation and solution. It does look silly to build a single application that requires two different sets of runtime files, and then only distribute one of them in the conda-pack.zip download. I'll send a note to the admins once I've got confirmation that this second machine is working properly.