This is startin to piece me off. Friday I just did a whole system restore because i couldn't fix my Explorer fatal errors (caused by rundll32) or my AIM error (caused by MSVCRT.dll) and lo and behold, yesterday, 3 days after doing the restore, here comes the MSVCRT.dll error again, causing both IE and AIM to crash. When AIM crashes i get the dreaded box with the red X in it that says "AIM" and if i hit more details it says MSVCRT.dll. When IE crashes, I get the big gray box, and i hit more details, and it says "ModName: MSVCRT.dll." It sucks because 90% of the sites on the net I can't go to or else I get that error. Google doesn't crash (thank god) and I searched the file on there, downloaded a new MSVCRT.dll to maybe replace the one i already have in the Windows\System folder, but the only problem is I can never replace it because when I try to, it says I can't because MSVCRT.dll is being used by Windows. Even when I end task every program running, it still says it's being used.

THIS SUCKS!

Somebody help.

I'm running Windows 98. Any help is GREATLY appreciated. Thank you!

Did you try F8 at startup to boot into safe mode? Usually does the trick, though I've never had to replace that file =\ Btw, are you running any type of firewall? If your not, you need to.

Sygate:http://smb.sygate.com/download/download.php?pid=spf

ZoneAlarm:http://download.zonelabs.com/bin/free/1012_zl/zlsSetup_50_590_015.exe

Good luck!
- Lotus

Hi Kle,
First off, while Lotus was trying to helpful DLL hell has absolutely nothing to do with firewalls or a lack thereof. I wouldn't recommend installing a firewall unless you want to add additional complexity, instabability, and reduce the over all performance of your system. My guess is AIM and IEXPLORE were both designed for newer versions of MSVCRT.DLL and you installed some older piece of software that overwrote a more recent copy.

You aren't going to be able to overwrite that file outside of DOS or possibly safe mode, however doing that manually is not a necessary job anyways. Just run an update package and let it overwrite the file while windows is still loading. Please download and install these updated Visual C++ Service Pack 6 runtimes (MSVCRT stands for MS Visual C++ Runtimes by the way):
http://download.microsoft.com/download/vc60pro/Update/1/W9XNT4/EN-US/VC6RedistSetup_enu.exe
Keep that file and you may want to re-install it periodically after installing other titles. It will always be safe to re-install this package even when it's out of date, because when it's out of date it won't overwrite anything, unlike whatever the program was that hosed your MSVCRT.dll.

By the way it should be noted that newer and far superior operating systems like Windows 2000 (best choice), Windows XP, and 2003 all have some built in file protection and will restore most system files if a program overwrites one of them with an outdated version. I would recommend Windows 2000, because XP and 2003 are still too new and are still loaded with bugs, though both are far more stable than Windows 98 or 98SE.

Cheers,
Christian Blackburn

You can learn more about this update at:

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q259/4/03.ASP&NoWebContent=1

Cheers,
Christian Blackburn

Originally posted by christianb:

"
First off, while Lotus was trying to helpful DLL hell has absolutely nothing to do with firewalls or a lack thereof. I wouldn't recommend installing a firewall unless you want to add additional complexity, instabability, and reduce the over all performance of your system.
"

You are absolutely correct christianb, a firewall has nothing to do with DLL hell. KLEShreen stated he was having problems, did a restore, then 3 days later the error popped up again. If it ran ok for 3 days, then went "bad", it sounds like it could be exploit related. Someone hitting a weakness in his OS. Todays internet is full of exploiters. I can't imagine not having a firewall today.

KLEShreen, I hope you get it figured out one way or another. Good luck my friend. Keep us updated.

- Lotus

Originally posted by Lotus:

"You are absolutely correct christianb, a firewall has nothing to do with DLLHell"

Here is the "rules" to follow when diagnosing/fixing DLLHell dynamic link library version build mismatches, & the how & WHY someone would want to put a different version build of a .DLL file into a folder with their executable as well:

NT based Os' by default, use different approaches for 32-bit versus 16-bit apps.
=================================================================================================

1.) For 32-bit apps, Windows NT searches for implicitly loaded DLLs at:

a. The .exe file directory.
b. The current directory.
c. The %SystemRoot%\SYSTEM32 directory.
d. The %SystemRoot% directory.
e. The directories in your Path.

* BUT if a DLL is listed as a KnownDLLs at this hive key/folder location:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager
With a type of REG_SZ entry & Value Name of the DLL without the extension and a data value of the DLL with the .DLL extension, then the search order then becomes:

aa. The %SystemRoot%\SYSTEM32 directory.
bb. The .exe file directory.
cc. The current directory.
dd. The %SystemRoot% directory.
ee. The directories in your Path.

** KnownDLLs are mapped at boot time. Rernaming or moving during a session has no effect.
You can alter this behavior by including the 8.3 DLL name in the ExcludeFromKnownDlls entry, a REG_MULTI_SZ value, & one per line in that comma delimited listing.

(This makes NT believe that the DLL is not listed in KnownDLLs.)

-------------------------------------------------------------------------------------------------

2.) For 16-bit apps, Windows NT uses KnownDLLs for both implicitly and explicitly load DLLs. The value is at:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WOW.

Here in that key, KnownDLLs is a REG_SZ value that lists 8.3 DOS formatted DLL names, & is separated by spaces.

Without a KnownDLLs entry, WOW searches:

a. The current directory.
b. The %SystemRoot% directory.
c. The %SystemRoot%\SYSTEM directory.
d. The %SystemRoot%\SYSTEM32 directory.
e. The .exe file directory.
f. The directories in your Path.

With a KnownDLLs entry, WOW only searches for them in the %SystemRoot%\SYSTEM32 directory.

-------------------------------------------------------------------------------------------------
3.) Windows 2000 Service Pack #3 (at least, & thus probably XP also) has instituted the SafeDllSearchMode Value Name, a REG_DWORD data type, at this hive key folder:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager.

A value of 0 keeps the current search order, & a value of 1 makes Win2k & programs search for DLL's & programs in this order:

a. Their own folder first
b. %SystemRoot%\System32
c. %SystemRoot%
e. The current directory
f. The folders in your %PATH% environment variable.

=================================================================================================



* Sometimes, developers know the compiler they used is older, & want to put a .DLL version of the lib they used into the folder WITH the executeable (because the first place by default an app will look for & load that lib dll from IS its own folder!).

Why do that? They may not have a choice, & the compiler they use, or the .DLL file they used is older & they called functions that returned say, integer 1/0 for true-false tests on function call return tests they use for success/failure of a function call... when MS rebuilds these sometimes, they change those function calls to return Boolean True/False instead of integer flag data, & poof... you get crashes especially if the program does not have err trapping code that's up-to-snuff in a case like this!

Sometimes, it happens right as you start a program (VB declare statements, Delphi pre-implementation header code that declares an API of somekind that is not masked by the compiler natively) OR when you make a particular program function call...

That latter is when they used LoadLibrary API function calls to load the .DLL (smarter, does not use as much RAM @ program startup, & if the person never uses the function? The program never loads the DLL into RAM consuming resources).

Either way, if you have the WRONG version of DLL online? You get hassles... err traps can stop the program from bombing, & version tests SHOULD be run prior to the function call from said DLL file, but it does not always get implemented by coders. Some coders just don't know this stuff, they are JUST coders... & have little system engineering level knowledge!

(ANYHOW: If the coders doing this make the mistake of putting it into a folder that is publicly accessible via the system %path% system-wide or userlevel environment (like in-memory .ini file programs use & get copy of for reference each time they load) then you see .DLL hell sometimes if the version their program calls expects say, an integer return value of 1 or 0, but instead the diff. build of the .DLL file sends back Boolean True/False instead...)

Yes, this happens, & it makes progs crash that do not have good errhandlers built into them OR do not do a Version build check prior to loading the DLL file they are calling... it's extra work too, around 10 lines each call made & is sometimes overlooked!

APK

P.S.=> Good 'rules-of-thumb' to follow up there, I put that very list into one of my latest programs in fact, "APK Duplicate File Finder Engine 1.0++" that seeks duplicated files by Name, Size, Time/Date Stamp, CRC-32, CheckSums, & lastly version stamps... this last one is for exe types of ALL kinds (including .DLL files & this rules table for replacing them is part of its help system)... apk

Additionally, for VB folks who run into "DLL Hell" issues as well:

http://support.microsoft.com/default.aspx?scid=fh;en-us;vbruntime&product=vbb



* Has runtimes latest builds for VB 3.0-4.0-5.0-6.0 downloads to help patch this issue...

APK

P.S.=> Shouldn't happen with 2000/XP/2003, but does on occasion, especially if someone overwrites or deletes older builds on their machine that a program needs/requires...

That's why you really have to WATCH-OUT when you go 'dll hunting', sometimes programs need builds other than the latest/greatest (programmers should put the dll file into the folder with the program in that case, but 'less seasoned' coders, or coders that are nothing BUT coders & have lesser understanding of the OS' mechanics, make this mistake!).

This is why in my "APK Duplicate File Finder 1.0++" program's code I put in 6 diff. checks on version of a file (Name, Size, Time/Date Stamp (touchy if file was moved, changes this is why on recreate & program warns you about using MOVE), CRC-32, Checksums, & VERSION builds (.exe type only all types are checked for this when exe types are hunted down)... DLL files are one time you cannot just "willy-nilly" go & replace files, there might be reasons some are online that are older!

On newer versions of NT based OS', in addition to system file protection CB or Lotus mentioned above being in place which watches the public system32 folder under %WinDir% -

The OS' also have "side-by-side" loading of diff. .DLL file versions that load them not only by name on old-school type DLL files, but by version stamping inside them! This helps stop that DLL hell issue some... what is next does alot more:

OLEServer DLL's and ActiveX/ocx files load/marshall by GUID, not name only, & that should help prevent that with those by loading a SPECIFIC version of a DLL for a program & the program references that file by GUID in memory, NOT by name only! apk

First I want to thank all of you guys for helping me out. These are the first really knowledgeable answers I've gotten from anywhere. I tried downloading the update that was first posted, from the Microsoft Downloads site, but of course, as is my luck, got a "resource that is needed seems to be corrupted" message and the exe wouldn't run.

So now what do we do?

Well, we do what any frustrated computer user does...we're goin to get a new computer on Saturday. Ours has been outdated for many a years (98, 650 MHZ, P3 Processor, no 3-d graphics card, etc.) so we'll be getting a new computer, with XP Home...and from what I've heard I'm sure I'll be running into problems with that, especially with installing new updates when we first get it, so I'll probably be back

Once again, thanks to all of you for the great help, very knowledgeable people here

You're welcome, we've been there ourselves is why we might appear "knowledgeable" on the subject... and it IS a huge pain in the you-know-what to run into!

(It's been one of the minor plagues MS has had to deal with, & in CB up there, you are talking to MS (or, he used to work there iirc) they've done alot to help fix it, but sometimes it still pops up in a situation like the one you are in...).

CB gave you what is the easiest method to cure it!

Me? (rhetorical question there) I just put out the rules & how it works & what to look out for, straight outta a program I created's 'help' section menu.

(So, you 'lucked out' in that I had all that text put together already to paste here for you. It's fairly complex, but once you get the general idea of how libs are loaded & searched in these Operating Systems, it's not so bad!)

* The program I mention above is coming out this week for CB (who asked for one like it in fact in another thread here) & others to use (coming out this week hopefully in a utilities suite I've been putting together & improving for the last 7++ years or so) to help find duplicated files on disk, & what to look out for when doing that for DLL files specifically to avoid what you are seeing!

APK

P.S.=> Oh, didn't mention this before but here goes:

There is a program MS puts out in the resource kit, a free one you can download called inuse.exe !

That program lets you replace files locked by another process, EVEN if currently being used (sometimes, you can rename them & copy in another version while they are being used & reboot to replace .DLL files & other files being used BUT, sometimes not... in the 'not' situation, this is when inuse.exe helps!)... apk

Well I finally got the new stuff hooked up...and yay, no problems :P

And for those of you in the thread who want to know...we got a HP Pavilion a520n 2.2 GHZ, AMD Athlon XP 3200+, 512 MB Ram, and we got it pre-loaded with the ATI All-In-Wonder that I see I have to buy more cable hookups to figure out. That should be boatloads of fun. I'll probably end up stopping by the XP Hardware part to figure that out in the coming days/weeks...

I found a solution to the msvcrt.dll error.

Find a newer version of msvcrt.dll (look at the date) and replace the one in your C:\Windows\System folder.

Here's what I did: Found all copies of msvcrt.dll on the PC. I found many copies and took the latest dated one and copied it to C:\. Then I rebooted into command-prompt-only mode and replaced the bad msvcrt.dll (located in C:\Windows\System) with the newer copy that I put in C:\.

Now it should work perfectly!
AnakiMana

Originally posted by AnakiMana:

"I found a solution to the msvcrt.dll error.

Find a newer version of msvcrt.dll (look at the date) and replace the one in your C:\Windows\System folder.

Here's what I did: Found all copies of msvcrt.dll on the PC. I found many copies and took the latest dated one and copied it to C:\. Then I rebooted into command-prompt-only mode and replaced the bad msvcrt.dll (located in C:\Windows\System) with the newer copy that I put in C:\.

Now it should work perfectly!
AnakiMana
"

That'll work many times, but sometimes it won't... read the rules about DLL replacement above, seriously, & you'll see why I state that, & why doing it by date sometimes is misleading... I wouldn't say this to you if it was b.s. either!

(Sometimes, there is a reason you see tons of the same .DLL named files online in diff. folders other than %WinDir%\System32)

When checking ESPECIALLY for executeable types (libraries too)? Date checking is NOT enough, trust me on that!

ALL Executeable files have versionbuilds in them (except .com type afaik)!

.DLL, .OCX, .EXE, .SYS, .VBX, .DRV, .VXD, .TLB, .SCR, .CPL, .386 & all other .exe types have versioning: This is a FAR more sure method of checking what is the most current, rather than relying SOLELY on time/date stamps (which can be altered by commands easily as well as the MOVE command believe it or not! Moving files alters their time/date stamp, try it... you will see what I mean)!

In fact, because of this, I wrote a program that helps folks find duplicate files primarily, & also helps them analyze which is REALLY the "most current" build of executeable type if repeated on disk as well!

It makes determinations of that by size, date/time stamp, CRC-32, Checksumming, & lastly name so you can make more sound judgements about file replacements...

(There are valid reasons why I did it like that, because of what is explained above & even WHY a programmer puts his version builds of .DLL files into folders where his program resides, instead of publicly accessible folders on the system %PATH% variable in the memory environment... Do read the above so you can see the explanations for it!)

APK

My computer recently has been acting up and in programs like limewire and internet explorer whenever i try to run them i get a messge box that says the program has caused an error in MSVCRT.DLL and then it terminates. Explorer still runs after the box appears but I cant run AIM, Limewire, or netscape. i need help. what do i do?

The MSVCRT.dll error is one of those ubiquitous ones that used to occur with a lot of frequency because certain programs installed over the latest Microsoft version of the dll and replaced it with one that was compatible with the software that was being installed. Try here http://www.microsoft.com/windows98/downloads/contents/WURecommended/S_WUFeatured/Libraries/Default.asp to reload the libraries.

i tryed restoring the libraries with form the link you just posted but its still doing it.=(

imt rying to replace the file manually but i cant get the computer in ms-dos mode. when i go to the start up menu its not an option

Why do you need to get into DOS to replace that file? If it's blocked by Windows File Protection, then WFPdisable is a good solution.

And, you might want to do a find on MSVCRT.DLL since it sometimes gets buried in subdirectories of different applications and is defaulted to when that application runs. Netscape used to be notorious for doing this.

Alright gurus, here is the million dollar question. It seems that XPSP2 (the one we should have waited for the service pack on). In it is version 7 of the msvcrt.dll which is just lovely UNLESS you are running Oracle and the Java client, in which case you NEED version 6 - which is provided with the JVM and a half dozen other programs. How do you get XP to unload the offesive (SP2) .dll and use the correct (v.6) .dll.

And don't tell me that the option is to switch to SQLServer...

Originally posted by kg4giy:

"How do you get XP to unload the offesive (SP2) .dll and use the correct (v.6) .dll."

Attempt to initially rename it while inside your Windows desktop explorer.exe shell FIRST, to msvcrtOLD.dll (etc.) & then copy in the version build of it you require in %WinDir%\system32...

Reboot once it's done so this is the ONLY possible version that will load from that publicly %PATH% accessible area.

IF it is locked against access & you CANNOT perform this?

Well then, you can do this same procedure from the recovery console (OR, DOS in your case booting to it for this since this is the Win9x/ME forums) where it will NOT be locked to replace this %PATH% accessible version with the one you need your apps to use.

(There is also the tool I mention above, inuse.exe (by Microsoft), for scripting in replacements of files (even IF locked while you are in Win32 desktop explorer shell) say, via logonscripts, for each end-user's workstation node on your LAN/WAN, etc.)

Additionally: There is a "hack" to the registry for loading/unloading ANY & ALL .dll files from memory once they are done being accessed as well here:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer

* Add in this DWORD value there & set it to 1 (hex or decimal doesn't matter with T/F boolean values) -

AlwaysUnload DLL

(REBOOT when done so it becomes effective/takes, etc.)

BUT, problem is with this last one? That runtime by MS might ALWAYS be getting accessed & never unloaded or not enough for it to "take" in your case - but, it is imo, one worth mentioning here as well as a possible fix for you.

Replacing the %WinDir%\system32 housed version of this DLL file, rebooting, & using this reghack for "alwaysunloaddll" might work IF this file is replaced with the version you have in that %WinDir%\system32 folder (unless the coders of the app you're having problems with hardcoded the path to it with LoadLibrary API calls in their code... probably not, but be aware that happens sometimes too, so they avoid .DLL hell with publicly placed .DLL file versions!)

Originally posted by kg4giy:

"And don't tell me that the option is to switch to SQLServer..."

It's not, you have means here to replace that build of msvcrt*.dll with older models that will work for you... try what I said above!



APK

P.S.=> Oracle ROX! And, reading the "RULES" I posted above for how DLL's work/load etc. above can help too...

Yes, it is a BIT long, but can help you understand HOW, WHEN, WHERE, WHY, & etc. of how dynamic link libraries etc. are loaded & searched on Win32 Os' as well... apk

We are on a windows NT server and we are getting the error regarding msvcrt.dll file. Does the inuse.exe program work with windows NT? We are running on an NTFS file system so i'm doubting it will work.

We started getting this error when a third party cd writing software program was installed.

No most programs don't open and we get the error ENTRY POINT NOT FOUND etc.....

Can someone assist me please? Windows is using the file i need to replace...........

Originally posted by whoopass:

"We are on a windows NT server and we are getting the error regarding msvcrt.dll file. Does the inuse.exe program work with windows NT? We are running on an NTFS file system so i'm doubting it will work."

Well, it should... since it's character mode/console terminal application VERY std. programming, & not REALLY a filesystem level tool (more dealing in bypassing locks on files iirc) it should work on just about ANY NT-based OS in console mode.

Try it, it cannot hurt anything... at worst it will "abend/err" & say it won't work is all @ most imo!

Recovery Console's another method, but I am NOT 110% sure it will install onto an NT 4.0 system, and I KNOW it won't on NT 3.5x since I tried that about a month back in fact here (it WILL install to disk but it WON'T BOOTUP TO RC & WORK).

Now, you COULD perform another OS install, newer OS and just to install the RC & use its copy command's methods to overwrite the file in question... that's a thought & POSSIBLE!

See this post for details on how that's done:

http://www.ntcompatible.com/thread30546-1.html

(BUT, in your case unlike that one? You could leave the 2nd OS install (in another folder, say C:\NT vs. default NT 3.5x/4.0 C:\WINNT one) & have IT copy over the files, & wouldn't even NEED Recovery Console really...

The files locked in your FIRST/ORIGINAL NT OS install wouldn't be locked by another 2nd OS installed that is booted up currently.

Heck, SO that said? WELL, you could do yours with another separate NT 4.0 installation into another folder really!

There are some catches though:

Like the %Program Files%\Common Files and IE files that would be out of sync between the 2 os installs (I cover that in that URL above) but simply service pack, IE and hotfix patching covers that if you do it to BOTH OS installs to "sync" them!

That's assuming you leave the 2nd OS install in place that is... you could techincally remove it when you're done!)

BUT, like in the url above? You could just dispense with (i.e.-> REMOVE) the second NT 4.0 installation when you are done doing this copy of this locked .DLL file... details on that for TOTAL removal, SHOULD be in that other thread URL too!

(Mostly? That's just editing boot.ini to pull the entries for the 2nd OS installation & burning its folder off, & then service pack + hotfix patching your first OS (so that the 2nd OS install files which are out-of-date get renewed & up-to-date again once more) & Service Pack patching Internet Explorer too for the SAME reasons!)



* This IS doable in your case, with a second OS installation of NT 4.0, not a newer OS or having to put in RC either!

(See, the MAIN reason a newer OS install is not the BEST way here is filesystems types/versions - Especially if that is a FAT filesystem there, you COULD safely do it... but if it is NTFS filesystem? Well, the NTFS version in NT 3.5x/4.0 might be an issue since NTFS version build changed/updated/upgraded on 2000/XP/2003....

BUT, again in your case? You wouldn't REALLY NEED a newer OS version (& thus, no NTFS version hassles either) install or RecoveryConsole... )

Yes, imo? A 2nd install of NT 4.0 to another folder can fix your original OS install since the original OS install's files are no longer locked in the 2nd OS installed being booted (and, even later remove that second OS install if you wish later as well)

* Get my point?

APK

P.S.=> Sorry for stating same basic idea 2x or more, but had to "think this one out" & edit it for detail so you DON'T mess up here...

It's pretty simple idea though using secondary OS installations, & used to be suggested by MS in fact to keep an alternate (but service pack + hotfix & IE patched fully matching original OS install) in place in fact for times like you are seeing, which were before Recovery Console (that intro'd in Win2k)... apk

How would i go about doing a parallel installation of NT into another folder/directory? More importantly how would I boot into this parallel installation if it's in a different directory other than the root directory?

Originally posted by whoopass:

"How would i go about doing a parallel installation of NT into another folder/directory?"

Oh, it's really SIMPLE man! The installation will detect another version of Windows NT & ask you IF you want to install over it etc. (do this NOT from inside another OS for the install, but from booting up from the Cd for installation).

Don't overwrite your existing one!

It will then ask you WHERE you'd like it installed disk(s) if you have multiple disks, wise... & then the foldername!

You will put it into a directory/foldername other than the NT 4.0 default of C:\WINNT... for instance, C:\NT...

Originally posted by whoopass:

"More importantly how would I boot into this parallel installation if it's in a different directory other than the root directory?"

The OS loader is intelligent, & guided by the C:\boot.ini file, and when you do multiple OS installs? C:\BOOT.INI gets written to in order to account for multiple Operating Systems on your harddisks!



* Very simple/easy & intelligent + flexible!

APK

Yo, saw this post about the msvcrt dll, and I fully agree, that thing's a pain.

I'm running Windows XP, and recently had to reinstall due to some strange program ****ups(programs refused to close when I told them to, and would take up 99% of my active CPU. Nasty thing.)

So this new reinstall was running great. I was installing the repretoire of windows updates that I usually do, and the very first update(a security update) caused my system to enter a state of nigh-irreversible hell. Somehow or another that update knocked out my msvcrt file completely. I was able to use a LKGC to get it back, but before I did that, not even safe mode would boot. And since my motherboard is a honkin piece of sod, I cant boot from CDs(word to the wise, dont buy Epox, they degrade in the oddest of ways. Yes, I tested many bootable CDs, many CD drives, et cetera). So that was a little less than fun.

So now that I have it back, sort of, my system is totally crippled. Windows media player was the first obvious casualty, going so far as to totally remove itself from existence. Most other media-related programs went pretty much belly-up as well, including the MSI PVS software by Intervideo. I KNEW that wasnt stable, but this is still ridiculous.

The biggest problem I face is that this also caused windows installer to go more than a little bad. Needless to say everything's a mess right now. Anyone got any one-step solutions for getting this sort of thing resituated? I'm guessing I could dig up another board and run a reinstall(again) and hope for some results, but I'd love it if I could do something short of that to solve this little canundrum.