PhilW believes that SxS COM with manifest is one of those “well kept secrets” that should be more well known. As the current maintainer of Windows SxS, I am absolutely thrilled to hear that.
That said, I have to admit that it is not the easiest thing in the world when something went wrong in Sxs. Typically you are left in a situation with no hint of what went wrong, and how to fix the problem.
In Vista some work is done to make Sxs failures easily diagnosable.
This article compares the experience of diagnosing Sxs failure in Windows XP and Windows Vista.
In VS 2005 VC80 CRT is fusionized (when a component is made into a Sxs assembly, we call it fusionized). When an application is compiled with VC 2005, VC will automatically create a manifest for it, and set it to depend on VC80 CRT. In order for the application to run, you have to install VC80 CRT in the machine first.
A common mistake is to xcopy the application to a different machine without installing the VC80 CRT redist in that machine.
A different common mistake is to compile the application in debug mode, and try to use the application in a machine with only retail VC80 CRT redist installed. Application compiled in debug mode will depend on the debug version of VC80 CRT, and there is no redist for it.
In both cases, the application will not launch due to Sxs failure (not able to find VC80 CRT.). We will use the second case as the example in our discussion.
So we have a test application.
The test application is compiled in debug mode, thus it depends on debug version of VC80 CRT.
Let’s try it on Windows XP.
Run it in cmd.exe.
(Text: The system cannot execute the specified program.)
Ok, the system cannot execute the specified program. That is not helpful.
Let’s try again with explorer.
(Text: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.)
Hmm, a little better, but still not helpful. Application configuration is incorrect. What application configuration? Reinstall the application may fix the problem, how?
Actually, the message we see in the explorer error dialog is the standard error message for Win32 error SXS_CANT_GEN_ACTCTX. Cmd.exe does not understand this error, so it shows a generic error message.
Whenever there is a Sxs failure, Sxs always logs information to system event log with source SideBySide. In our case, Sxs logs three messages to system event log.
In other cases, Sxs may log more (or less) messages. The oldest message usually contains the more direct information on what exactly is the failure. Other messages typically just repeat the same information, or more generalized information. You should always read the oldest message relevant to the failure to find the cause of the Sxs failure.
In our case, the three messages are identical
It tells us that Sxs cannot generate activation context for test.exe.manifest, and the reason is that some referenced assembly is not installed. In our case, since we only have one dependency, so we know VC80 Debug CRT is not installed. In the case when we have multiple dependencies, we still don’t know which dependency is missing.
OK. Enough about Windows XP. Let’s try it on the latest and greatest Windows Vista.
First, run it in cmd.exe.
(Text: The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log for more detail.)
Much better. It tells us that there is a Sxs problem, and directs us to the application event log for more information.
(note, in Windows Vista, due to a security change, Sxs can no longer write to the system event log. So the information is written to the application event log.)
Let’s open the event viewer.
Here it is. There is one message with source SideBySide. And it tells us what exactly the problem is: Dependent assembly VC80 debug CRT cannot be found. Even better, it tells us to use sxstrace.exe for detailed diagnosis.
(I created a custom view to only show SideBySide messages in event viewer. You should look for messages from source SideBySide under Windows Logs\Application.)
So what is the sxstrace.exe thing?
Recall that in .Net framework, fusion binding log is the ultimate diagnosis tool for assembly binding failure. Sxstrace is basically the same idea. We want to show exactly how Sxs is searching for the dependencies so you can figure out how to fix the problem.
Fusion binding log is using a custom log format — HTML and the file is stored in internet explorer cache by default. Sxstrace uses the ETW model.
ETW model has three components: Controller, Providers, and Consumers. In our case, sxstrace.exe is both the controller and the consumer, and Sxs is the provider.
Sxstrace.exe is shipped in Windows Vista and resides in %windir%\system32.
Here is the usage for sxstrace.exe:
To see the Sxs tracing, we have to enable the trace first.
(Enable tracing requires admin privilege. You have to run sxstrace.exe in an elevated cmd.exe window.)
Now let’s run the test application, and stop the tracing.
The trace generated is a binary file. We have to translate it to human readable text.
And here is the output:
You can see exactly how Sxs probes for the dependent assembly VC80 debug CRT.
This concludes the article. I hope you find the Windows Vista experience helpful to diagnose Sxs failures.