none
[RESOLVED] Windows 7 x64 - Mixed version x64 .NET Framework v2.0 files RRS feed

  • Question

  • My Framework 2.0 has been partially overwritten with wrong version files. This happened between Windows Update and a few apps I installed below.

    Yesterday I noticed I a whole bunch of bluetooth devices without drivers in the device manager. I decided I'd go get drivers for them. I did something I would normally not do and that is install non-essential 3rd party apps, and have two of the same genre of 3rd party app installed at the same time.

    I installed Nokia's software (My phone is Nokia), Windows Mobile Device Center 6.1 (A forum suggested it'd give the drivers I needed) and lastly I turned on Windows Update to try and get them from there. The result was that 4 of the 8 missing driver bluetooth devices disappeared which was good, but the downside was a windows update in the install process blue screened my pc. The first bluescreen I 've had on this os install. The error was bad_pool_header 0x00000019. Since then my Ati Catalyst doesn't load. Neither will eventvwr.msc. That snap-in is unhappy. Services.msc and device manager work no problem.

    ***************
    SFC /SCANNOW
    ***************
    I tried sfc /scannow and that got to 6% then "Windows Resource Protection could not perform the requested operation.". I checked the log and the last bit shows an error

    2010-02-20 21:30:33, Error ... Facility=(system),Code=51 (0x0033)] .... SysCreateFile(flags = (AllowFileNotFound|AllowSharingViolation), handle = ... OBJECT_ATTRIBUTES {...; on:[37]"\??\D:\Program Files\\DVD Maker\en-US"; ..., disp = Invalid)

    I removed DVD Maker thru the control panel then deleted it's folder, no change with sfc. There is something odd in the path in the OBJECT_ATTRIBUTES, one of the pathing slashes is escaped but the other's aren't. I'm not sure if that extra slash could be behind it.

    ***************
    SFC /VERIFYONLY
    ***************
    Doing an sfc /verifyonly returns these probs:

    [SR] Cannot repair member file (for each of the below 4 files)

    iskpotab.ttf...
    mscorwks.dll...
    mscormmc.dll...
    FeedbackTool.dll, Version = 6.1.7100.0, ...AMD64..., hash mismatch
    Hashes for file member \SystemRoot\WinSxS\amd64...feedbacktool...\FeedbackTool.dll do not match actual file FeedbackTool.dll
    This component was referenced by Microsoft-Windows-Foundation-Package ...amd64~~6.1.7100.0.WindowsFoundationDelivery
    Could not reproject corrupted file C:\Windows\System32"\[l:32{16}]"FeedbackTool.dll, source file in store is also corrupted

    ***************
         MSIEXEC
    ***************
    I Bing/Googled some of the error messages I was getting and everything pointed to Framework problems. I wasn't able to install any Framework updates (Win7 doesn't allow it) but also because the Windows Installer gave errors and all the setup files crashed. One article suggested something was changed:

    In my services/msiserver/imagepath reg key it seemed to have the wrong value:

    %systemroot%\System32\msiexec .exe /V .

    I'm on x64 so changed it to: (which fixed me not being able to install anything)

    %systemroot%\SysWOW64\msiexec.exe /V

    ***************
    .NET FRAMEWORK 1.1
    ***************
    I uninstalled the 1.1 Framework from my system using the control panel then using the cleanup/removal tools I saw online. To get it back in I slipstreamed the copy and used the method suggested here in the forums and there is no change.

    Running the .NET Framework Setup Verification Utility on 1.1 SP1 fails Product verification. The error logs shows missing .dlls in Assembly\GAC, Framework\v1.0.3705 and Framework\v1.14322, I don't believe this is a problem.

    ***************
    .NET FRAMEWORK 2
    ***************
    This seems to be the problem. I've been getting error messages from launching installers and opening apps. When I Bing the error messages they keep referring to v2.0 probs.

    With my x86 copy I can ngen.exe update it but My Framework64 copy fails on ngen.exe update. It opens a dialog window with the title "mscorsvw.exe - .NET Framework Initialization Error", "C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll could not be loaded".

    Running the .NET Framework Setup Verification Utility on 2.0 SP2 fails on Netfx20TestApplication.exe, "WindowsApplication1 has stopped working".

      -Problem Event Name: BEX64 (This is the event name I'm seeing in most errors now)
      -Fault Module Name: StackHash_d87e (Most errors are saying StackHash)

    When I look at my Framework64/v2.0.50727 files, they are all version 8.0.50727.4918 with the exception of mscorwks.dll which has no version information and mscordacwks.dll which is .4927 instead on .4918

    When I look at my x86 Framework/v2.0.50727 files, they are all 8.0.50727.4918 except for 4 which are .4927:

      -SOS.dll
      -mscorwks.dll
      -mscordacwks.dll
      -mscorlib.dll

    These 4 have appeared in error messages/logs since yesterday.

    I have no Previous Versions for any of the files. All my restore points start around the time I ran Windows Update turned on System Restore. The solution to this is to install the Framework v2.0 for my Win version but there is no such thing so I'm going to try to hunt down matching versions manually.

    I have to Install Windows again in a few months because the RC period is ending but currently I have a large amount of development work on this machine and I can't afford the downtime of setting up a new installation right now.


    • Edited by cancausecancer Saturday, February 20, 2010 9:45 PM Marking as resolved
    Saturday, February 20, 2010 8:17 PM

Answers

  • Ok. I got it fixed. I mounted the win7rc's install.wim with GImageX (install.wim is located in the win7rc disc's \sources folder) and replaced the .dlls that had wrong versions with the ones from the disc. The mscorwks.dll in the x64 folder had no version data so keep your eye out for .dlls without versions (add the Product Version column to your Details view when looking at the folders).


    The problem looks like it was caused by an update for RTM that didn't work with RC, the version numbers are here:

    http://en.wikipedia.org/wiki/.NET_Framework_version_list
    • Edited by cancausecancer Saturday, February 20, 2010 9:47 PM Adding link to framework list
    • Marked as answer by cancausecancer Saturday, February 20, 2010 9:47 PM
    Saturday, February 20, 2010 9:44 PM