Fix for “Automation Server Can’t Create Object” (Updated)

Updated to include sample .REG file of solution. Read on.

I love foobar2000. I absolutely love it. It’s lightweight, straight-forward, and so customizable it’s ridiculous. I loved it even more when I found out spotifoo (a skin for foobar2000), which although now a couple of years old, does everything I want (including scrobbling, play count and love) and still has a very uncluttered and space-effective interface. However, recently, and with no indication as to what caused this change, when I started up foobar, most of the panels of the spotifoo skin were replaced by an “Aw, crashed! :(” message, and I was getting multiple errors about an unexpected script issue. I checked the console, and it was full of “Automation Server Can’t Create Object” errors. I have been trying to find a solution for this for weeks, I even switched to MusicBee for a while; but I HAD to get my foobar2000 back. Finally, I’ve just found the solution, but it’s in no way an elegant one.

So, what’s going on here is that certain ActiveX Objects, including Scripting.FileSystemObject and WScript.Shell, have been deemed unsafe. I would imagine this is a recent change that must’ve been applied to my Windows 7 installation via Windows Update, given how I wasn’t having these problems for years now. And the JavaScript files included with spotifoo, as well as most other foobar2000 skins which use the WSH Panel Mod, had calls to new ActiveXObject(something), where something was one of those unsafe ActiveX Objects. This is a quite popular error outside of foobar2000 as well, as a number of developers seem to have similar issues when using those calls.

Talking about the WSH Panel Mod extension for foobar2000, the most popular solution is to go to its preferences and disable (untick) Safe Mode. That didn’t work for me, as it was never ticked in the first place.

Next, I followed a catch-all solution that’s plastered in message boards around the web, saying to enable the “Initialize and script ActiveX controls not marked as safe for scripting” in the “relevant zone” in the Security tab of Internet Options. Well, first of all, this is a local script, running from my local drive. No relevant zone is there in Windows 7 anymore, as the My Computer zone has been hidden. However, that didn’t stop me, and I took it five steps too far. I enabled that setting in all of the zones, went to the Advanced tab to enable “Allow active content to run in files on My Computer”, and even went to the hidden My Computer zone (Zone 0) in the registry to manually set the appropriate flag (1201) to 0, thus enabling unsafe ActiveX controls from local scripts. Not even that worked. I was getting immensely frustrated. Mind you, this is not a safe solution. You’re opening yourself to all kinds of trouble if you allow all unsafe ActiveX controls to run without warning. If you’re thinking “but I’m not using Internet Explorer, what do I care?”, then you haven’t read what I’ve written above. ActiveX controls can be initialized from inside .js and .vbs files, practically anything the Windows Scripting Host supports. So even if you don’t browse using Internet Explorer, malicious scripts can still take advantage of that security setting, if disabled.

So, what did work? Hat tip to user semjon from this thread (with further explanation here), you can selectively disable any and all security checks on specific ActiveX controls. So, first, you need to go to HKEY_CLASSES_ROOT in the registry, find the GUID of the control you want to mark as safe (in my case, {72C24DD5-D70A-438B-8A42-98424B88AFB8} for WScript.Shell and {0D43FE01-F093-11CF-8940-00A0C9054228} for Scripting.FileSystemObject), export the keys, and add these lines to the .reg file before you merge it back into the registry:

[HKEY_CLASSES_ROOT\CLSID\{GUID HERE}\Implemented Categories]

[HKEY_CLASSES_ROOT\CLSID\{GUID HERE}\Implemented Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4}]

[HKEY_CLASSES_ROOT\CLSID\{GUID HERE}\Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}]

Adding these two GUIDs as Implemented Categories for that object marks it as safe across the system. However, there’s three caveats:

  • If you’re running a 64-bit version of Windows, you need to make a copy of the whole key (with the above lines) and make sure to merge it under the Wow6432Node key of HKEY_CLASSES_ROOT as well. I’m not sure if just including the Implemented Categories will suffice, but I copied the whole key just in case.
  • You’re most probably going to run into issues merging the key back into the registry, as the permissions of all HKEY_CLASSES_ROOT subkeys are pretty strict. What you need to do is first get ownership of the keys to your user account from TrustedInstaller, then give your User Account (or the Administrators group) full permissions on those keys. If you don’t do that, you’ll most probably get “Error accessing the registry” messages. If you get sufficient permissions, you should get a successful message after attempting to merge the exported and edited .reg file.
  • This is still unsafe. You’re still marking two ActiveX controls that were marked unsafe as safe to run throughout your computer. So do this on your own risk, fully aware of the possible consequences.

So, this is how I finally got my foobar2000 installation back and fully running, and how I got most of the foobar2000 skins that had stopped working to work again. Note that you need to follow the above procedure for every different kind of ActiveXObject that’s being created by the skin’s scripts and that causes the Automation Server Can’t Create Object error. It’s a tedious, unsafe procedure, so it’s up to you to determine if the value of being able to keep using your favorite foobar2000 skin is worth the trouble.

For me, there’s no question.

ImageMy spotifoo 1.3.1 skinned foobar2000 installation

UPDATE: I’m seeing a lot of traffic from, and I’m happy that I was linked to by br3tt (a.k.a. Falstaff), the creator of spotifoo. So, to further help anyone reading this post, here’s a sample .reg file of how I fixed the Scripting.FileSystemObject-related errors. As I said above, in order to fix any other ActiveX Object by marking it as safe, you only need to replace the GUID (that’s after CLSID in each of the lines) with the one that’s assigned to that specific object. To find that, you need to do a search through HKEY_CLASSES_ROOT\CLSID, of course.


2 thoughts on “Fix for “Automation Server Can’t Create Object” (Updated)

  1. Thanks for the help. Got the scripts going again in Windows 7 SP1. They control an HP Wireless Printer. Looks safe to me. I don’t know why MS doesn’t let customers know what these security updates do. I usually boot Linux but occasionally in Windows for some apps.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s