This Should Work, & If Not, We Can Try Other Things
This one got me interested, SO... I will now attack the original issue, from the original poster, & NOT the last one I responded to!
(Trog100's)
(Trog100's method's pretty good, but does have SOME minor limitations noted above (and major ones, if you don't have that 2nd OS install, but if you do? Make sure it's updated to the max (or rather, the same level this setup is @ OS level) & you can try what he's about)):
(Jimmy2004 - perfect time to test those NTFS read/write capable drivers builds of Linux I noted in the other section though, eh? Good thing it's NOT YOUR RIG, here though & now!)
Anyhow/anyways:
humm k, this thing is poping up on my taskbar.
!(yellow triangle around it)
Windows - Corrupt File
The file or directory C:\windows\system32\msvcrt.dll is corrupt or unreadable. Please run the chkdsk utility.
Well I ran the chkdsk in my windows 32 folder and the problem remains
.
Any help when someone has the spare time, is greatly apriciated.
You COULD try chkdsk /f C:\, but that's risky in THIS case... read on, you'll understand why, & there may be a way to FIX this w /out that even!
==========================================================
That lib is doubtless locked by your running applications while under the Win32 GUI explorer shell logon so other than chkdsk /f above, or a floppy copy I noted last post of mine while using RC?
You CAN/SHOULD first try to:
-------------------------------------------------------------------------
1.) Copy a version build of file using your windows bootup, because it still sounds useable.
RENAME THE OLD MESSED UP ONE, FIRST THOUGH (msvcrt.old for example)!
Then, copy the new one over to %systemroot% (C:\WINDOWS\SYSTEM32 typically) as either:
msvcrt.new
OR
just as msvcrt.dll
This is so you do NOT have to rename it using RC later (a LOT of programs written in MSVC++ depend on this file, so you have to have it there, BUT technically? Windows File Protection/System File Protection SHOULD have taken care of this, but apparently either has not, OR this is particular to SOME APP, that has this file in its local folder on disk (this too, should NOT be a problem, because OLEServer DLL's allow for side-by-side assemblies in memory, but we will work on that, per my P.S., if THIS does not work!).
(TRY TO GET SAME VERSION OF THIS DLL FILE: YOU CAN CHECK THAT BY RIGHT-CLICKING ON THE FILE & CHECKING ITS PROPERTIES, ALL executables files have this (well, most) EXCEPT FOR MOST DRIVERS, NOT WIN32 PE TYPE IIRC, & IF IT IS NOT TOO BADLY CORRUPTED IT WILL REPORT IT)
* THIS IS ALL ASSUMING IT IS & NOT A "DLL-HELL" ISSUE, & SOME PARTICULAR APP ONLY IS BITCHING HERE...
More on that in my p.s., because THAT is "curable" potentially, as well if need be here. We have to determine this first though.
I state all this, because odds are, that is the public version being used for any apps with open handles to it (unless they have a copy in their own folder, which would be called first prior to %PATH% environment searchway found ones)...
-------------------------------------------------------------------------
2.) WHEN COPYING? Rename the original 'bad' one though, to msvcrt.dll (renaming the old one, first, to msvcrt.old).
-------------------------------------------------------------------------
3.) Reboot, using Recovery Console, get to C:\WINDOWS\SYSTEM32 (or wherever your %WinDir%\system32 is, this can vary (I just use the typicals for this example, adapt & improvise on your end when necessary), & DELETE the msvcrt.dll (now renamed to msvcrt.old) you have now that is corrupted.
-------------------------------------------------------------------------
4.) NOW, finally, rename the version of it you copied to %SystemRoot%\msvcrt.NEW, to its correct name, msvcrt.dll (if you renamed it period initially that is, & were unable to rename the orig. corrupt one to msvcrt.old, this SOMETIMES happens, but rare).
-------------------------------------------------------------------------
5.) REBOOT!
-------------------------------------------------------------------------
6.) Once REBOOTED? TEST! See if it still happens...
==========================================================
* It would be GREAT to see which app it is that is complaining as well, because another way to fix THAT (dll hell thing) would be to copy the version of MSVCRT.DLL runtime lib it needs, to its OWN folder...
(If it is a problem app that is, & if said problem child app was NOT 'hardcoded' internally to call upon a particular one someplace on disk? You may be in business, that way).
There is a tool in the reskit called inuse.exe that allows file renames/replacements as well, stopping the need for renaming msvcrt.dll -> msvcrt.old (to get the corrupt one out of use on next bootup) & copying in the new uncorrupted msvcrt.dll to %systemroot% afterwards, but I don't recall if this MSVC++ runtime is constantly locked, or not, even IF renamed first.
We're going to find out though... see, the main thing here that SHOULD have prevented this in the first place (public %systemroot% msvcrt.dll being messed up) is "System File Protection" (in Windows NT-based OS since Win2k iirc)... this is why I am thinking it MAY be a "DLL HELL" version mismatch on some APP, not the OS & the fileversion in %systemroot%... but, we will see!
APK
P.S.=> IF IT IS A PARTICULAR APP? Then, analysis tools like tasklist.exe /m (this switch, possibly others, because it WILL list what process uses WHAT modules) can help here, there are others, but that one comes to mind in that instance!
If after your testing, IF this problem persists... we can pursue THAT, as needed, IF NEEDED, later after test reboot... apk
