iScreensaver has been updated to version

iScreensaver version 6.8.3 fixes an issue that could cause screensaver installers to crash silently on macOS non-English language systems (such as Korean). It also has improved error reporting, and has been tested with the latest versions of Windows 11 and macOS 12.1 Monterey. Any authors distributing screensavers to non-English macOS users should update and rebuild as soon as possible, and other authors are encouraged to update and rebuild when convenient.

Release Notes
We are pleased to announce the release of iScreensaver version 6 which supports macOS 10.11 (El Capitan) through 11 (Big Sur) and Windows 7 through 10. Read about Version 6

deployed screen save cpp error

We built a screensaver and installed it on a test computer. We got the SCR file from that computer and put it on our SCCM folder to be used via group policy deployment. If I or any user runs the scr file from the network location, it plays fine. If they copy it to their local drive, for example C:\Temp\, and run it. It plays fine. These are computers that have never had any iscreensaver software installed. So this is expected for a deployment. The screen saver should play without any install.

However. Once we setup the group policy deploy it copies the file to "C:\Windows\System32\" and sets the registry keys as mentioned in the guide. It shows as the set screensaver and that its enabled. However, when you try and run it users get the following error:

Runtime Error

..\..\..\..\Common\loaderx86.cpp: 662

Failure Condition: 0


I know the guide said to use "C:\Windows\" but our policy is to use system32 for these kind of system settings. Why is having the file in windows vs system32 causing this error and what does it mean?


  • I'm not sure, but I have a hunch: For maximum compatiblity, iScreensaver builds 32 bit SCR files (this is because 32 bit files will run on either 32 or 64 bit systems, but 64 bit SCRs will only run on 64 bit systems.)

    There is a common misunderstanding with Windows system folders, which has to do with very poor naming choices by Micrsoft. On a 64-bit system:

    • System32 holds 64 bit EXEs and DLLs
    • SysWOW64 holds 32 bit EXEs and DLLs

    You can see the confusion: the one with "32" in the name holds 64 bit files, and vice-versa!

    Can you try putting iScreensaver's SCR file (which is 32 bit) inside the SysWOW64 folder instead?

  • You hit the nail on the head there. Changed our deployment script to push to the Syswow64 folder instead and it'll fire right up. Gotta love Microsoft.

  • Glad to hear you solved it! ?

Sign In or Register to comment.

☰ Copyright ©1995-2021