MSI 1935 and 2908: Assembly Component Errors During .NET Installations

Fix it now

Setup tried to place a component into the assembly cache and the store refused it. Microsoft’s message for 1935 carries an HRESULT, an assembly interface, a function and the assembly name, and that HRESULT is the part that decides what to do next. 2908 is the same stage reported as a component that could not be registered.

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All

1. Reboot before anything else. A pending file rename from an earlier install blocks assembly writes until the machine restarts, and it costs you nothing to rule out.
2. Note the HRESULT from the 1935 message. 0x800736B3 means the referenced assembly is not installed; 0x800736CC means a file does not match the verification information in its manifest.
3. Run the three commands above. The third line is only needed if the application requires .NET Framework 3.5.
4. Reboot again, then run the application’s installer from an elevated Command Prompt.

Run Microsoft’s .NET Framework Repair Tool as well if the framework itself is suspect. It is a free download from Microsoft and it detects and repairs the installed versions in place.

If the application installs you are finished. If it does not, the next section explains what the assembly store checks and which HRESULT you are looking at.

Why it happens

Shared managed and native components are not copied into the application folder. They go into a machine-wide store, versioned and signed so two applications can use different versions of the same library side by side. When an MSI installs such a component it hands it to that store rather than writing a file, and the store validates it before accepting it.

1935 is the store refusing the hand-off. Microsoft publishes it with placeholders for the component, the HRESULT, the assembly interface, the function and the assembly name, which makes it one of the more informative installer errors once you know to read past the number. 2908, published simply as “Could not register component”, is the same stage reported a level up.

The HRESULT decides everything. Two are common enough to memorise. 0x800736B3 is Win32 14003, ERROR_SXS_ASSEMBLY_NOT_FOUND – the referenced assembly is not installed on the system, so a prerequisite is genuinely missing. 0x800736CC is Win32 14028, ERROR_SXS_FILE_HASH_MISMATCH – a component’s file does not match the verification information in the component manifest, which means what is on disk has been altered or damaged and a repair is the route back.

1936 and 1937 are frequently lumped in as “more of the same” and they are not. Microsoft publishes 1936 as an assembly that is not strongly named or is not signed with the minimal key length, and 1937 as a signature or catalogue that could not be verified or is not valid. Both point at signing rather than at a damaged framework, and repairing .NET will not touch either.

Full reference

Decoding the HRESULT the message carries

The pattern generalises: any 0x8007xxxx code is a Win32 error wrapped as an HRESULT, and the last four hexadecimal digits in decimal give the number to look up. That turns most unfamiliar 1935 messages into something you can read without searching for the whole string.

The four assembly numbers, as published

1936 and 1937 send you somewhere quite different from 1935. Both describe a signing problem with the assembly being installed, so the questions are whether the package was built correctly, whether the catalogue travelled with it, and whether the machine trusts the publisher – not whether the framework is damaged.

Repair order that does not waste an afternoon

1. Restart. Rule out a pending file rename before anything else, because everything below fails while one is outstanding.
2. Read the HRESULT and decide whether you are missing a prerequisite or repairing damage. They have different fixes and doing both takes twice as long.
3. DISM /Online /Cleanup-Image /ScanHealth to find out whether the component store is damaged before you try to repair it.
4. DISM /Online /Cleanup-Image /RestoreHealth, then sfc /scannow. In that order: sfc draws its replacements from the store DISM repairs.
5. The .NET Framework Repair Tool last, on a store that is already healthy.
6. Restart once more and rerun the application’s installer as the first thing you do.

Things worth knowing before you start removing frameworks

• On current Windows builds .NET Framework 4.x is part of the operating system. It cannot simply be uninstalled and reinstalled, and the standalone installer will decline to run.
• .NET Framework 3.5 is an optional Windows feature whose payload is fetched on demand, so enabling it needs either internet access or a local source.
• Community cleanup tools that strip framework versions can leave a machine unable to service itself. Take a system image first if you use one at all.
• A 1935 that appears on several unrelated machines at the same time usually follows an update rather than local damage; check what was deployed that week.
• If the assembly named in the message belongs to the application rather than to Microsoft, this is the vendor’s problem and the log is what they need.

Every code this article covers

Confirm the fix worked

1. Rerun the application installer and confirm it completes without rolling back.
2. Run sfc /scannow and confirm it reports no integrity violations.
3. Run DISM /Online /Cleanup-Image /ScanHealth and confirm no component store corruption is detected.
4. Launch the application and exercise a feature that uses the shared components, so you know they really registered.
5. Install a second application that depends on the same framework, which tells you the store is healthy generally.

Questions people ask about this