Controlling your MMC Snap-ins on 64-bit Operating Systems

Controlling your MMC Snap-ins on 64-bit Operating Systems

  • Comments 2
  • Likes

Over the last couple of weeks, we have worked with a few customers on some MMC issues that they have been experiencing when launching MMC Snap-ins on 64-bit Windows systems.  Most customers have reported that the issue normally surfaces after installing the Hotfix from KB942589 on Windows Server 2003 systems.  On the systems in question, there will be several SideBySide errors in the Event Logs, similar to the ones below:

Event Type: Error 
Event Source: SideBySide 
Event Category: None 
Event ID: 59 
Date: (Date) 
Time: (Time)
User: N/A 
Computer: (Computer Name)
Description: 
Generate Activation Context failed for C:\WINNT\SysWOW64\mmc.exe. Reference error 
message: The referenced assembly is not installed on your system. 

Event Type: Error 
Event Source: SideBySide 
Event Category: None 
Event ID: 59 
Date: (Date)
Time: (Time)
User: N/A 
Computer: (Computer Name)
Description: 
Resolve Partial Assembly failed for Microsoft.Windows.Common-Controls. Reference 
error message: The referenced assembly is not installed on your system. 

Event Type: Error 
Event Source: SideBySide 
Event Category: None 
Event ID: 32 
Date: (Date)
Time: (Time)
User: N/A 
Computer: (Computer Name)
Description: 
Dependent Assembly Microsoft.Windows.Common-Controls could not be found and Last 
Error was The referenced assembly is not installed on your system. 

As you can see, the error messages are not terribly descriptive and don’t really give any indication as to possible causes.  The initial assumption is that there is some issue with SideBySide on these systems (we’ll be covering SideBySide in more detail in a future post).  However, that is actually not the case.

If you use Process Monitor to monitor the startup of the MMC.EXE on a working and a non-working system, what you would actually find is that prior to the installation of the hotfix, MMC.EXE was being launched from the Windows\System32 folder.  However, after installing the hotfix, MMC.EXE was being launched from the Windows\SysWOW64 folder.  The MMC.EXE does not launch because it is attempting to use the 64-bit SideBySide files.  So … what happened?

Microsoft 64-bit operating systems can run both 32- and 64-bit MMC’s (MMC32 and MMC64).  However, a 64-bit MMC cannot run a 32-bit snap-in, nor can a 32-bit MMC run a 64-bit snap-in.  However, it is possible to control which version of the MMC is executed by using command-line parameters, or switches.  Stepping away from Windows Server 2003, and looking at 64-bit operating systems in general, let’s take a look at how this would work using the Computer Management snap-in.  Most administrators are familiar with right-clicking on the Computer icon and selecting the “Manage” option from the context menu.  When you launch the Computer Management snap-in in this fashion, the 64-bit version of MMC is launched.  However, to launch the 32-bit version, you could either run MMC.EXE –32 from the Run line, or run COMPMGMT.MSC –32 from the Run line.  You can confirm which version is running by looking in Task Manager:

Right-click on the Computer Icon and choose Manage Run COMPMGMT.MSC from the Run Line
image image

Run COMPMGMT.MSC –32 from the Run Line
image  

So as you can see by looking in Task Manager, the 32-bit version of MMC is distinguished by the *32 suffix, denoting the application as 32-bit.  Thus there are ways to manipulate the version of MMC.EXE used.  When specifying a console file there are some considerations.  If MMC64 is started from the command line without the –32 or –64 switch, but the command line does contain a console file name, then MMC64 examines the console file before determining which version of MMC remains in execution using the following logic:

  1. If all snap-ins referenced by the console file are available in 64-bit form, then MMC64 remains as the executing version and the rest of the logic below is ignored
  2. If not all of the snap-ins are available in 64-bit form, but they are all available in 32-bit form then MMC64 starts MMC32, MMC32 executes the console file and MMC64 terminates, ignoring the rest of the logic below.
  3. If the number of unavailable 64-bit snap-ins is a subset of the unavailable 32-bit snap-ins then MMC64 remains as the executing version and ignores the rest of the logic below
  4. If the number of unavailable 32-bit snap-ins is a subset of the unavailable 64-bit snap-ins, then MMC64 starts MMC32 and MMC64 terminates, and ignores the last logical step below
  5. If none of the previous logic steps yields a conclusion, then the user is presented with a prompt to either choose which version of MMC to execute, or to cancel the operation.

And that will do it for this post.  Hopefully this helps answer some of your questions.

Additional Resources:

- Blake Morrison

Share this post :
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Regarding your comment below:

    "As you can see, the error messages are not terribly descriptive and don’t really give any indication as to possible causes.  The initial assumption is that there is some issue with SideBySide on these systems (we’ll be covering SideBySide in more detail in a future post).  However, that is actually not the case."

    We operations folks see this a lot (and have for years). When will the dev teams at Microsoft begin to address the pervasive inaccurate and undescriptive error messages in MS products rather than just mention them (almost in passing) as you have?

  • Great post, explained really well and I could really understand. Thank you.