MS tech support is useless.
June 3, 2012 7:47 AM Subscribe
Windows Explorer (aka "the thing I use to look at my directories of files" ) on my computer is crashing because of the "Visual C++ Runtime Library", but Microsoft's help library isn't very helpful. Can you guys do more?
I'm getting the following error:
Like that other user, I did try a system restore, but no dice. What I'm trying to open is the CONTROL PANEL on my system, of all things. Am using a Dell Inspiron, Windows 7, chrome. I'm also a frankenstinien mix of "know some computer basics" and clueless"; I can be walked through some basic things if you give me clear instructions. I may also want to know WHY you're asking me to do things.
Help?
I'm getting the following error:
“Microsoft Visual C++ Runtime Library" This application has requested the runtime to terminate it in an unusual way. Please contact the application's support team for more information” error at startup.I googled for solutions to the error, but all I found was this link here, where someone advises a user with the same problem to try starting the computer in safe mode. However, it's not clear what starting the computer in safe mode is supposed to achieve.
Like that other user, I did try a system restore, but no dice. What I'm trying to open is the CONTROL PANEL on my system, of all things. Am using a Dell Inspiron, Windows 7, chrome. I'm also a frankenstinien mix of "know some computer basics" and clueless"; I can be walked through some basic things if you give me clear instructions. I may also want to know WHY you're asking me to do things.
Help?
Actually, if you can go to Start > Control Panel > Administrative Tools > Event Viewer > Windows Logs > System and then look for any errors with the same "Visual C++ Runtime Library" text in the description, does it contain any more information that that?
posted by Blue Jello Elf at 8:04 AM on June 3, 2012 [1 favorite]
posted by Blue Jello Elf at 8:04 AM on June 3, 2012 [1 favorite]
I would try running the System File Checker. This will scan your system files and make sure nothing is corrupted.
Open a command prompt:
-Open the start menu. Type "cmd"
-Right-click the "cmd.exe" entry and click "Run as administrator"
Run SFC:
-type "sfc /SCANNOW"
This will take a little while.
posted by Adamsmasher at 9:26 AM on June 3, 2012
Open a command prompt:
-Open the start menu. Type "cmd"
-Right-click the "cmd.exe" entry and click "Run as administrator"
Run SFC:
-type "sfc /SCANNOW"
This will take a little while.
posted by Adamsmasher at 9:26 AM on June 3, 2012
Agree with Blue Jello Elf, it's probably some program that is hooking into Explorer. That's a fairly generic error message, not explorer-specific.
Try running Sysinternals Process Explorer, http://live.sysinternals.com/procexp.exe, set the lower pane view in the View menu to DLLs, and look for any non-Microsoft DLLs. Try uninstalling any applications listed, at least temporarily, and see if that fixes it.
posted by Boobus Tuber at 10:08 AM on June 3, 2012
Try running Sysinternals Process Explorer, http://live.sysinternals.com/procexp.exe, set the lower pane view in the View menu to DLLs, and look for any non-Microsoft DLLs. Try uninstalling any applications listed, at least temporarily, and see if that fixes it.
posted by Boobus Tuber at 10:08 AM on June 3, 2012
Response by poster: Haven't installed anything.
I'm trying the System File Checker now, although even just pulling up the start menu and then typing "cmd" to find it gave me the same error. Although I was able to pull it up anyway; it's running the scan now.
Although, i've also just noticed now that my battery is not charging. It says it's charging, but it's been plugged into the charger for over 4 hours and is still at 0% power.
posted by EmpressCallipygos at 12:40 PM on June 3, 2012
I'm trying the System File Checker now, although even just pulling up the start menu and then typing "cmd" to find it gave me the same error. Although I was able to pull it up anyway; it's running the scan now.
Although, i've also just noticed now that my battery is not charging. It says it's charging, but it's been plugged into the charger for over 4 hours and is still at 0% power.
posted by EmpressCallipygos at 12:40 PM on June 3, 2012
Response by poster: And Boobus: How DO you "set the lower pane view in the View menu to DLLs"? I ask it to view the lower pane, but it shows me an empty lower pane.
posted by EmpressCallipygos at 12:43 PM on June 3, 2012
posted by EmpressCallipygos at 12:43 PM on June 3, 2012
Response by poster: Just ran the system file checker. It didn't find anything wrong.
posted by EmpressCallipygos at 12:57 PM on June 3, 2012
posted by EmpressCallipygos at 12:57 PM on June 3, 2012
Here is something to try, which may fix it fast, and if not you may want to undo it.
In Windows Explorer, in "Search libraries" box type msvcrt*.dll and let it search. You wil have to search in "Computer", not whereever Windows Explorer starts searching.
You are looking for all copies of the files MSVCRT.DLL, MSVCRT20.DLL, and MSVCRT40.DLL on your drive.
Let it finish and see what you have - there are likely different versions of the files. Look at the ones in the /Windows/System32 directory, and those are the correct ones. You have just verified those using SFC. Most of the others in different dirctories should be the very sames file, by filesize and filedate.
If there are any versions different than in /System32, probably with smaller filesize and earlier dates, right-click each one of those other versions and rename each different version to MSVCRT.OLDDLL, or MSVCRT20.OLDDLL or MSVCRT40.OLDDLL, then reboot and try things. If the duplicate versions are exactly the same as the ones in /System32, let them be and don't rename.
I'm 99% sure this will be a quick (and a proper, if not elegant) fix. If this doesn't fix it, undo it by searching the same way and renaming the .OLDDLL files back to .DLL, and something else has to be done.
posted by caclwmr4 at 1:16 PM on June 3, 2012
In Windows Explorer, in "Search libraries" box type msvcrt*.dll and let it search. You wil have to search in "Computer", not whereever Windows Explorer starts searching.
You are looking for all copies of the files MSVCRT.DLL, MSVCRT20.DLL, and MSVCRT40.DLL on your drive.
Let it finish and see what you have - there are likely different versions of the files. Look at the ones in the /Windows/System32 directory, and those are the correct ones. You have just verified those using SFC. Most of the others in different dirctories should be the very sames file, by filesize and filedate.
If there are any versions different than in /System32, probably with smaller filesize and earlier dates, right-click each one of those other versions and rename each different version to MSVCRT.OLDDLL, or MSVCRT20.OLDDLL or MSVCRT40.OLDDLL, then reboot and try things. If the duplicate versions are exactly the same as the ones in /System32, let them be and don't rename.
I'm 99% sure this will be a quick (and a proper, if not elegant) fix. If this doesn't fix it, undo it by searching the same way and renaming the .OLDDLL files back to .DLL, and something else has to be done.
posted by caclwmr4 at 1:16 PM on June 3, 2012
I very much doubt this is a problem in the c runtime dlls. This is caused by applications using the runtime improperly, such as passing null when they shouldn't, or passing improperly terminated strings, etc.
One easy thing you can do is run tasklist /m explorer.exe from a command line to see what modules explorer has actually loaded. Something that is not a Microsoft DLL may stand-out here.
The best way to assign blame is to run the explorer process in a debugger. You can download the debugging tools for windows as a stand-alone package from MSDN here. I recommend overriding the default installation and just installing to c:\debuggers (this is what we did at MSFT, it makes it much easier to have a path without spaces in the name).
Once you have the debugger installed, file these instructions to setup image file execution options for explorer.exe. In step 9 use c:\\debuggers\\ntsd -g instead of the supplied value (since you probably don't have Visual Studio installed).
Now perform the steps to reproduce the crash, i.e. launch the Control Panel view. Instead of crashing, now, it should hang and the debugger window which opened when you launched it should be sitting at a prompt. Type the following commands:
!symfix
.reload
kP1000
The first two command will try to get MSFT public symbols loaded (may take a few minutes, be patient). The last command instruct the debugger to print the most recent 1000 stack frames (which just ensures you get them all... there should be less than 50).
Now, at the very top you should see msvcrt (the c runtime). Below that should be the culprit DLL. If you're not sure, post the output here. MeFi mail me if you run into issues (I'm on my mac so I'm typing this from memory).
More on NTSD here.
posted by jeffamaphone at 1:34 PM on June 3, 2012
One easy thing you can do is run tasklist /m explorer.exe from a command line to see what modules explorer has actually loaded. Something that is not a Microsoft DLL may stand-out here.
The best way to assign blame is to run the explorer process in a debugger. You can download the debugging tools for windows as a stand-alone package from MSDN here. I recommend overriding the default installation and just installing to c:\debuggers (this is what we did at MSFT, it makes it much easier to have a path without spaces in the name).
Once you have the debugger installed, file these instructions to setup image file execution options for explorer.exe. In step 9 use c:\\debuggers\\ntsd -g instead of the supplied value (since you probably don't have Visual Studio installed).
Now perform the steps to reproduce the crash, i.e. launch the Control Panel view. Instead of crashing, now, it should hang and the debugger window which opened when you launched it should be sitting at a prompt. Type the following commands:
!symfix
.reload
kP1000
The first two command will try to get MSFT public symbols loaded (may take a few minutes, be patient). The last command instruct the debugger to print the most recent 1000 stack frames (which just ensures you get them all... there should be less than 50).
Now, at the very top you should see msvcrt (the c runtime). Below that should be the culprit DLL. If you're not sure, post the output here. MeFi mail me if you run into issues (I'm on my mac so I'm typing this from memory).
More on NTSD here.
posted by jeffamaphone at 1:34 PM on June 3, 2012
Response by poster: In Windows Explorer, in "Search libraries" box type msvcrt*.dll and let it search.
The problem is that Windows Explorer IS the program where I'm getting the error, so I can't open it!
posted by EmpressCallipygos at 2:03 PM on June 3, 2012
The problem is that Windows Explorer IS the program where I'm getting the error, so I can't open it!
posted by EmpressCallipygos at 2:03 PM on June 3, 2012
Oh - then reboot to Safe Mode and try the same thing. Starting in Safe Mode will absolutely use the correct versions in /System32, allowing to you to search for and rename the incorrect versions.
posted by caclwmr4 at 2:09 PM on June 3, 2012
posted by caclwmr4 at 2:09 PM on June 3, 2012
Response by poster: ....And now everything is working fine again. My battery is charged up to 100% full, and I'm able to run everything no problem.
Huh.
posted by EmpressCallipygos at 2:13 PM on June 3, 2012
Huh.
posted by EmpressCallipygos at 2:13 PM on June 3, 2012
The problem is that once Windows loads an old version of msvcrt.dll or the others, if a newer program needs a later version, Windows does not get rid of the old version in (or indexed in) RAM, it just crashes the program that wants the newest version. WindowsUpdate keeps the ones in /system32 up to date, but it doesn't look around all over the disk. Also, older improperly written programs can install an old version in their own directories - if you run such a program, it loads it own old version, then you start a new program like Windows Explorer which then crashes.
This is officially known as "DLL Hell" and has been a "feature" of Windows since the beginning, which MS has never fixed properly, although such problems happen less now.
posted by caclwmr4 at 2:15 PM on June 3, 2012
This is officially known as "DLL Hell" and has been a "feature" of Windows since the beginning, which MS has never fixed properly, although such problems happen less now.
posted by caclwmr4 at 2:15 PM on June 3, 2012
Response by poster: Well, I'm marking this "resolved" because the problem I was having seems to have resolved itself*, but an amended form of my question actually still remains: I understand that in Safe Mode, I would be able to ascertain where the problem areas on my computer are. But my question is, HOW would I be able to do that? Would I need to look for anything specific, or would some menu or screen pop up that says "this is where your problem is" or anything like that?
* That is, the Windows error problem is resolving itself. However, my battery is also seeming to have a greatly diminished capacity for holding a charge, but I'm dealing with that by cursing and getting another battery from a different manufacturer than the cheap hacks I got this last one from.
posted by EmpressCallipygos at 7:18 PM on June 3, 2012
* That is, the Windows error problem is resolving itself. However, my battery is also seeming to have a greatly diminished capacity for holding a charge, but I'm dealing with that by cursing and getting another battery from a different manufacturer than the cheap hacks I got this last one from.
posted by EmpressCallipygos at 7:18 PM on June 3, 2012
Sorry, late back, but just to answer your question, In Process Explorer, View->Lower Pane View->DLLs. You need to select explorer.exe in the upper pane.
posted by Boobus Tuber at 2:49 AM on June 4, 2012
posted by Boobus Tuber at 2:49 AM on June 4, 2012
Response by poster: Oh - then reboot to Safe Mode and try the same thing. Starting in Safe Mode will absolutely use the correct versions in /System32, allowing to you to search for and rename the incorrect versions.
But that was precisely my question - I know the steps to follow in order to start my computer in safe mode. But all instructions stop there, and do not go on to say exactly "now that my computer is IN safe mode, NOW what?"
What I mean is: you say it will allow me to search for and rename the incorrect versions. But I don't know what "incorrect versions" are, or how I would know them to look at them. What am I looking for? What are the next steps I take once my computer is in Safe Mode, and sitting there looking at me asking me what I want to do?
posted by EmpressCallipygos at 7:56 AM on June 4, 2012
But that was precisely my question - I know the steps to follow in order to start my computer in safe mode. But all instructions stop there, and do not go on to say exactly "now that my computer is IN safe mode, NOW what?"
What I mean is: you say it will allow me to search for and rename the incorrect versions. But I don't know what "incorrect versions" are, or how I would know them to look at them. What am I looking for? What are the next steps I take once my computer is in Safe Mode, and sitting there looking at me asking me what I want to do?
posted by EmpressCallipygos at 7:56 AM on June 4, 2012
I thought I did list enough simplified instructions, but here is more detail:
I was guessing that, in normal mode, Windows was loading something in Startup which loaded some old versions of the MSVCRT* files right on startup, right as it boots - this is not too uncommon. So if you then started a different newer program, like "Windows Explorer For Windows 7", that requires the most up to date versions, it would crash, because Windows already had old versions loaded.
In Safe Mode, Windows ignores anything in Startup - it starts "clean" and stripped down just to make it possible to manually fix a lot of things. After you are booted in Safe Mode, if you start Windows Explorer as the first thing, it would not find any old MSVCRT* versions in memory, and it would load the up to date versions from /System32.
From there, you could use Windows Explorer to search for all the MSVCRT* versions anywhere on the disk. Then check the up to date versions in /System32 to see what filesizes and filedates those have - those should have the newest filedates and probably but not always the largest filesizes, then rename any different old versions you find anywhere else on the disk to (whateverdon'tchangethisside).OLDDLL
The reason for that is that old programs can look in their own directory first, where they might have placed their own old versions of the MSVCRT* files. If an old program can't find its own old versions where it expects to find them in its own directory, it "tells" Windows that, then Windows next looks in /System32 and loads the current versions from there.
The newest up to date MSVCRT* versions are supposed to be backwards compatible with older programs. That is not always the case though, but that would be a more complex problem. In 99% of cases just renaming the old versions and forcing/tricking Windows to load the newest versions usually works.
This "DLL Hell" problem has been going on since Windows 3.0 in 1990. MS has patched it and patched it and patched it with every new Windows version, but still has not solved it. They have only reduced how often this problem occurs, but it does still occur, and I thought that was the problem you had.
But, if you find some old program/CD written for Windows 95 or 98 or NT4 and install it on Windows 7, it very likely will cause a problem like you had, and my instructions here will very likely fix it. It's easy to just say old programs won't work on Windows 7, but nearly all of them can and the problem is really just Dumb Microsoft.
posted by caclwmr4 at 12:36 AM on June 13, 2012
I was guessing that, in normal mode, Windows was loading something in Startup which loaded some old versions of the MSVCRT* files right on startup, right as it boots - this is not too uncommon. So if you then started a different newer program, like "Windows Explorer For Windows 7", that requires the most up to date versions, it would crash, because Windows already had old versions loaded.
In Safe Mode, Windows ignores anything in Startup - it starts "clean" and stripped down just to make it possible to manually fix a lot of things. After you are booted in Safe Mode, if you start Windows Explorer as the first thing, it would not find any old MSVCRT* versions in memory, and it would load the up to date versions from /System32.
From there, you could use Windows Explorer to search for all the MSVCRT* versions anywhere on the disk. Then check the up to date versions in /System32 to see what filesizes and filedates those have - those should have the newest filedates and probably but not always the largest filesizes, then rename any different old versions you find anywhere else on the disk to (whateverdon'tchangethisside).OLDDLL
The reason for that is that old programs can look in their own directory first, where they might have placed their own old versions of the MSVCRT* files. If an old program can't find its own old versions where it expects to find them in its own directory, it "tells" Windows that, then Windows next looks in /System32 and loads the current versions from there.
The newest up to date MSVCRT* versions are supposed to be backwards compatible with older programs. That is not always the case though, but that would be a more complex problem. In 99% of cases just renaming the old versions and forcing/tricking Windows to load the newest versions usually works.
This "DLL Hell" problem has been going on since Windows 3.0 in 1990. MS has patched it and patched it and patched it with every new Windows version, but still has not solved it. They have only reduced how often this problem occurs, but it does still occur, and I thought that was the problem you had.
But, if you find some old program/CD written for Windows 95 or 98 or NT4 and install it on Windows 7, it very likely will cause a problem like you had, and my instructions here will very likely fix it. It's easy to just say old programs won't work on Windows 7, but nearly all of them can and the problem is really just Dumb Microsoft.
posted by caclwmr4 at 12:36 AM on June 13, 2012
« Older What happens if an open-source app intentionally... | Getting better at Spanish this summer Newer »
This thread is closed to new comments.
posted by Blue Jello Elf at 8:01 AM on June 3, 2012 [1 favorite]