CheckAndLogOSInformation 0x87d00215

CheckAndLogOSInformation failed with 0x87d00215

CcmSetup failed with error code 0x87d00215

Running on ‘Microsoft Windows 7 Enterprise ‘ (6.1.7601). Service Pack (1.0). SuiteMask = 272. Product Type = 18


CcmSetup failed with error code 0x87d00215



0x87d00215 Is a WMI error and generally indicates WMI database corruption.  Very odd since this was during the imaging process and there really should have been no way for WMI to be corrupted, especially since Microsoft confirmed that they are simply making a call to “select * from Win32_OperatingSystem”

This in the end was one potential random symptom of a bad processor in the system.  See Core Gone Wild for full details.


To Reboot, or Not to Reboot, that is the question…

I have to thank a friend of mine for doing all the testing on this, but many times I’ve starred at the “Should Configuration Manager enforce specific behavior regardless of the application’s intended behavior?” options along with the Return Codes tab.

Reboot options on the “User Experience” for a Deployment Type

Return Codes and application intended behavior

Below is what happens when selecting the four different options in the drop down, assuming a 3010 return code from the application.

No specific action.
Software Center “Restart required” text: No
3010 causes reboot?  No
3010 System Center “Status” text: Installed

Whether or not the software is Required or Available, the computer is not forcibly restarted and no reboot prompts are displayed.

Determine behavior based on return codes:
Software Center “Restart required” text: Might be required
Application return code: 3010

If the installation is Required then following dialog is displayed.

If the software is Available then the computer is not forcibly rebooted and no countdown timer is displayed, only an optional reminder which the user can cancel.

Below is the text displayed in the Software Center when the application gives a return code of 0. 


The software install program might for a device restart:
Software Center “Restart required” text: Might be required
3010 causes reboot?  No
3010 System Center “Status” text: Installed

If the application installation does cause a reboot it is not logged as an error condition within the Software Center.

Whether or not the software is Required or Available, the computer is not forcibly restarted and no reboot prompts are displayed.  This setting is used to ensure that if the application installer itself (e.g. setup.exe) performs a reboot of the system, the SCCM agent is able to handle this scenario and doesn’t consider it to be failure.

Configuration Manager client will force a mandatory device restart:
Same behavior as Determine behavior based on return codes however it is not based on the return code of the application package.

Launch mode is not defined

If you’re smsts.log file ends with “Launch mode is not defined”, and you’re using a Prestart command / custom interface on your SCCM Task Sequence Boot image, the solution is simple:

DON’T REMOVE the DVD or USB boot disk PRIOR to seeing the “Installation Progress” Window/Progress bar!

Expression evaluation encountered a fatal error (0x80070002)

Main symptom was that App was not showing up in Software Center even though it was deployed.

This one showed up in a couple logs with different messages, so here they are so Google can index them:


Expression evaluation encountered a fatal error (0x80070002).
CLocalAppHandler::DiscoverApp failed (0x80070002).
Deployment type detection failed with error 0x80070002.
Failed to perform detection of app deployment type Install(Install, revision 2) for system. Error 0x80070002


Rejecting ScopeId_9d0608fa-33a2-4479-bb1b-078d045f7274/RequiredApplication_c9bc4f8b-958b-4243-a9f2-36fe91daee65/2 due to evaluation error

ScopeId_9d0608fa-33a2-4479-bb1b-078d045f7274/Application_c9bc4f8b-958b-4243-a9f2-36fe91daee65/2 :- Current State = Error, Applicability = Unknown, ResolvedState = None, ConfigureState = NotNeeded, Title = My Broken App

ScopeId_9d0608fa-33a2-4479-bb1b-078d045f7274/DeploymentType_5d322e96-cd06-40e4-9743-bc090cba35be/2 :- Current State = Error, Applicability = Unknown, ResolvedState = None, ConfigureState = NotNeeded, Title = Install


Not sure how it happened, maybe the SP1 upgrade or a scripting issue.  The app did not have detection rules, and therefore could not detect whether it needed to be installed.  Seems as though 0x80070002 in Windows land is typically some sort of file not found error, but looks like SCCM might be returning it as a generic “I couldn’t find something” error.

Core gone wild

What would you do if someone called you and said every time a computer finished imaging, it was missing a bunch of software?  Well, look at the logs of course, but after that is where things get interesting….

I had one computer in particular that was brought to me that was consistently throwing file errors, and the first thought was there had to be some download corruption.

But time and time again, everytime the image was loaded, errors would show up, not always on the same software, but at least a few various ones.  The hard drive was replaced first, but no improvement, then the RAM, and finally the motherboard.  No dice, issue still persisted.  The only thing left was to focus on the CPU.

After swapping the CPU from a known working computer, walla! No more errors!  And more importantly, the “bad” CPU reproduced the same random issues in the known computer.  Now, to get that CPU replaced…

Problem was, the PC OEM’s built in hardware diagnostics said everything was fine.  Even the Intel CPU diagnostics, came up clean.  In the process of installing all sorts of test utilities, I noticed a new pattern… There was no pattern.

Sometimes while simply double clicking a download to run an install, I’d get an extraction error, and then a minute later, it would run fine.  Intel’s own diagnostics tool is one example, here’s the error:

So how is this randomness possible?  When you run program, the Windows kernel will schedule the thread on an available logical processor, and considering this was a quad core computer, that means at random, it would be executing on one of the 4 cores.  To test the theory, I started setting the affinity to control which core it was running on.  Since processor affinity is inherited by child processes, I first open a command prompt and set  the affinity there, and started running my tests.

In classic suspenseful style, each core that I ran it on worked correctly, until the very last one was tested, and boom, error popped up.  I now had a %100 repeatable test, every time I had the affinity set to CPU 3, it would error out %100 of the time, any of the other CPU’s selected, and there was no error %100 of the time.

So why is a CPU issue manifesting as a file extract error?  Let’s look a little deeper at the files themselves.  Running Sysinternals Process Monitor, we see that the Setup.exe is extracting files to our Appdata temp folder, no surprises here:

But let’s grab a these files out of the temp folder before closing the error, and then do the same with the extracted files when there is no error.  Then using your favorite hex editor/comparison tool, look at the differences.

If you look closely, every where there is a difference between the good file and the bad file, the data is off by a value of 4.  From this point I can only speculate what is going on in the CPU.  It is decompressing a file, so maybe there’s a math error, or maybe a transistor somewhere that thought it gets set to 1 is still a 0, not sure.  That’s another job and another career for someone else to figure out….