Matt Pietrek wins my unofficial prize for the funniest call stack of the year:
0006e57c 65158435 somemodule!_AssertMsgW +0x80
0006e58c 65158448 somemodule!READ_ME_READ_ME_READ_ME_READ_ME +0x16
0006e598 65158459 somemodule!This_is_NOT_necessarily_a_somemodule_issue +0xd
0006e5a4 6515846a somemodule!Check_your_SETUPERR_dot_LOG_file_for_failures +0xd
0006e5b0 6515847b somemodule!Some_inf_file_probably_failed_to_install +0xd
0006e5bc 6515848c somemodule!Which_caused_a_cascade_failure_to_here +0xd
0006e5c8 6515849d somemodule!So_before_doing_anything_please_check_setuperr_to_find_that_component +0xd
0006e5d4 651584ae somemodule!Please_dont_mail_xyzalias_before_reviewing_log_file +0xd
0006e5e0 651584d4 somemodule!Fixing_the_components_inf_will_resolve_this_assert +0xd
0006e5f0 65158748 somemodule!Scroll_up_to_see_debug_assert_message_with_more_details +0x22
0006e82c 651587f5 somemodule!CallInstallCode +0x85
But, wait, whatever is the component failing in this way, this call stack actually describes an insidious problem that can happen during Windows setup. The issue is related with the way the Optional Component manager works. You can get more details about this specific behavior in this KB article.
Let’s take a particular example of silent failure. During GUI mode setup, the Optional Component manager wakes up and installs various optional components that are installed by default. Yes, that’s right – there are such optional components that are installed by default! One of them is COM+. But, here is the catch – the way OC Manager works is that it will silenty abort the installation of these default components if there is an error in the OC Manager component installation chain. In other words, if one component fails to install, the OC manager will end up not installing any other components.
A classical failure pattern (which is pretty rare, but we saw it in the field) is this one. Let’s say that the CD has some scratches, and some file (needed by OC manager or one of the default components) cannot be read from the media. The user is asked “Abort”/”Retry”/”Ignore”. If the user chooses “Ignore”, which is also the default for unattended installs, then OC Manager will then silently stop installing this component, and any other components that use OC. You won’t see any errors in the event log. The end result is hard to diagnose, but one way to spot the problem is to search for OC_COMPLETE_INSTALLATION in the %windir%\*.LOG %windir%\*.ERR and file for OC manager failures. Of course, look in the section generated by the latest installation details.
C:\WINDOWS>findstr OC_COMPLETE_INSTALLATION %windir%\comsetup.log
COM+[0:55:58]: Start OC_COMPLETE_INSTALLATION Component = com Subcomponent =
COM+[0:55:58]: End OC_COMPLETE_INSTALLATION Return Value = 0
COM+[11:55:22]: Start OC_COMPLETE_INSTALLATION Component = com Subcomponent =
COM+[11:55:22]: End OC_COMPLETE_INSTALLATION Return Value = 0
COM+[11:57:26]: Start OC_COMPLETE_INSTALLATION Component = com Subcomponent = com
COM+[11:57:47]: End OC_COMPLETE_INSTALLATION Return Value = 0
If you don’t see these lines, then your next step will be to look in %windir%\setuperr.log or even %windir%\setupact.log to get more details about this installation failure.