iScreensaver Logotype
iScreensaver 5.2 has been released, and provides support for macOS High Sierra 10.13. Please read the 10.13 High Sierra Tech Note as well as the Release Notes. macOS 10.14 Mojave is under investigation, and is not yet recommended.

[Solved] Screen saver will not work when copied to C:\Windows\System32 on WIndows 8/10

edited September 25 in General Discussions
We are running into an issue with a screensaver which has be created with iScreensaver. It works great if the LIBS and SCR file are copied to C:\Windows. But when it is copied to C:\Windows\System32, we receive an error stating "Unable to open data file. File is corrupt or missing".

I have copied the exact same files to both directories multiple files with the same results. Should the screensaver run from the C:\Windows\System32 directory?

Comments

  • Make sure you copy ALL files that were in the LIBS folder - there are some files & folders that aren't normally visible and were probably not copied over. Also, you can't change the name of the screensaver or LIBS folder as they refer to each other.

  • All the files. including the files in the archives directory, have been copied. The names have not been changed. As I said before, the exact same files have been copied to the C:\Windows and C:\Windows\System32 folder. They work when launched from the Windows folder, but display the error when launched from the System32 folder. We are planning to distribute this screensaver to a many desktops, but it has to run from C:\Windows\System32 due to the policies we have in place.
  • Shorter answer: what you are trying to do is unsupported and not recommended. Screensaver files belong in the Windows folder.

    Long answer:

    Why are you trying to move the files to the System32 folder? There is a common misconception that "System32" is for 32 bit apps, but it's actually the location for 64 bit apps - you can thank Microsoft for this confusing naming scheme.

    See https://www.geeksforgeeks.org/system32-folder-64-bit-operating-system/
    or
    https://stackoverflow.com/questions/949959/why-do-64-bit-dlls-go-to-system32-and-32-bit-dlls-to-syswow64-on-64-bit-windows

    iScreensaver 4.5 and 5.0 are 32 bit apps, and they will not function in the 64 bit system folders.

    Also, in addition the Windows OS is very particular about the location of screensaver files - it really prefers them in the Windows/ folder instead of the System/ folder.





  • We have been running screensavers from the C:\Windows\System32 folder for years without any issues. I found this while searching the internet.

    According to the documentation for iScreensaver Designer(TM) 3.5

    * Windows: The saver will now function as a saver if installed in a subfolder of C:\WINDOWS (this allows manual
    installation into other folders for locked-down systems, i.e. C:\WINDOWS\SYSTEM32 )
    New In 3.1
    General Improvements

    https://iscreensaver.com/legacy/downloads/iScreensaver.pdf

  • You are correct, but that's for version 3.5.

    That being said you might be able to get it working in 5.0.

    What's interesting is that your error message suggest that the SCR file is launching (which would not be the case if the LIBS folder was missing and the DLLs couldn't be located) but then it's having trouble finding the data folder (the .Archive folder which will be inside the LIBS folder).

    Are you sure you kept the SCR and Libs folder as siblings? If you put the SCR inside the Libs folder it might cause this error.

  • ... and again, the most likely cause of the error is a missing or mis-named Archive folder and data files within it.
  • The SCR file and LIBS folder were definitely copied to the system32 folder separately. All the files were definitely included in the LIBS and Archive folder.

    I tried deleting the LIBs folder from all folders but the C:\Windows\System32 folder where the SCR file is. So the error I am receiving now is "Failed to locate Framework DLL".

    I am running procmon.exe when launching the screensaver. The SCR file is trying to locate the file RBGUIFramework.dll. Procmon shows that it checks for the file in multiple folders in the path, but it never checks for it in C:\Windows\System32\ folder where it is located.

  • The files should be named "Savrname.sCR" and "Savrname Libs" - assuming you have the "Use Short Name" option selected when you built it. You can not change either of these names after building.

    From your original test, it seems like you had the libs folder named correctly, but it was missing the Archive folder or the files inside it.

    Please go back to your original test (where the app would launch, but couldn't find its data file ) and capture system logging DbgView tool: https://docs.microsoft.com/en-us/sysinternals/downloads/debugview

    You may get a better error message.

  • The LIBS folder and SCR names have not been changed. The names are "VZSAVER Libs" and "VZSaver.scr".

    Previously I had the "VZSAVER Libs" folder and the "VZSaver.scr" file copied to the "C:\Windows" folder as well as the C:\Windows\System32 folder so I could test it from both locations. That's when I received the first error.

    After that I removed it from "C:\WIndows" and only have it in C:\Windows\System32. That's when I started receiving the Framework DLL not found error message.

    After that I decided to use procmon.exe to try and narrow down what is causing the error. When the SCR file is launched, Procmon.exe shows that the SCR file never looks for the RBGUIFramework.dll in the "C:\Windows\System32\VZSAVER Libs" folder. It looks in every possible folder but that one.
  • Think I may have found a solution. I copied the LIBS folder and SCR file to both C:\Windows\System32 folder and C:\Windows\SysWOW64 folder and the SCR now launches from the C:\Windows\System32 folder.
  • I will do more testing with that to see if it is a viable solution.
  • That's good news, and thanks for sharing the solution. I think the problem gets back to the confusing nature of the those folders: the System32 folder is actually for 64 bit apps (on a 64 bit system). It seems like in more modern windows versions (8, 10) the rules have changed a bit.
Sign In or Register to comment.