Main Forum > Tweaking.com Support & Help
Registry backup crashes Win10, auto mode. MSVBVM60.DLL bug?
Julian:
I was just curious because I know of a horrible crack attempt on windows repair aio that actually breaks all the repairs and causes damage to the system and the reason is the idiot who made the crack would place that file in the directory and patched that file with their version of the dll. ... You never mess with runtime files..
Okay now I've seen an issue where registry backup crashes but it still makes the backup its all in the way it gets closed automatically... Can you check to see if you are still getting the backups created?
pol098:
--- Quote from: Julian on May 19, 2016, 11:38:37 am ---I was just curious because I know of a horrible crack attempt on windows repair aio that actually breaks all the repairs and causes damage to the system and the reason is the idiot who made the crack would place that file in the directory and patched that file with their version of the dll. ... You never mess with runtime files..
Okay now I've seen an issue where registry backup crashes but it still makes the backup its all in the way it gets closed automatically... Can you check to see if you are still getting the backups created?
--- End quote ---
Thanks again. For avoidance of doubt: I started using the MSVBVM60.DLL that I had on my machine after migrating from Win7/64 to Win10/64 (in SysWow64). I then used one from WinXP/32, then the oldest (Win98) and newest I could find (in the program directory). I haven't tried to patch any of them (I would if I had any idea what was happening). They all fail at exactly the same place relative to an export (as described in previous messages),
With every version of the DLL, registry backup works 100% when invoked manually, 0% when run automatically 5' after reboot and login (default using Task Scheduler). The event logs are virtually identical for all versions (different absolute addresses, of course). I'd expect systematic (and time-consuming) assembly-level debugging might eventually work, as I know where the program abends, but I have other things to do ...
Best wishes
Julian:
place this dll in your c:\windows\syswow64 (for windows 64 bit) the syswow64 is where all 32bit dll goes
then run this in cmd (Make sure its an elevated cmd other wise you will get an error 800a0046)
cd \windows\syswow64
regsvr32 c:\windows\syswow64\MSVBVM60.DLL
let me know if you get a crash.
oh and please delete the dll in the rb program folder it should never be placed in there lol....
pol098:
--- Quote from: Julian on May 19, 2016, 01:17:41 pm ---place this dll in your c:\windows\syswow64 (for windows 64 bit) the syswow64 is where all 32bit dll goes
then run this in cmd (Make sure its an elevated cmd other wise you will get an error 800a0046)
cd \windows\syswow64
regsvr32 c:\windows\syswow64\MSVBVM60.DLL
let me know if you get a crash.
oh and please delete the dll in the rb program folder it should never be placed in there lol....
--- End quote ---
Thanks. Summary: this DLL version is the one I was using when the problem first manifested, and I posted a detailed log in another thread at the time. In other words, I've already done this and posted the results at the time.
The file you attach, MSVBVM60.DLL 6.0.98.15, is exactly the one that was on my Win10/64 machine when the problem first manifested (not just the same version number, byte-by-byte identical). As it happens, I posted exactly the information you request in antoher thread, before starting this one: the full event log for it (showing v6.9.98.15) is here:
http://www.tweaking.com/forums/index.php?topic=4281.5 Reply#5 of 19 April.
I copy the event log entry from that post:
Faulting application name: TweakingRegistryBackup.exe, version: 3.4.0.1, time stamp: 0x56f4a2b2
Faulting module name: MSVBVM60.DLL, version: 6.0.98.15, time stamp: 0x49b01fc3
Exception code: 0xc0000005
Fault offset: 0x000c9ba6
Faulting process id: 0x2040
Faulting application start time: 0x01d19a3622cb4882
Faulting application path: C:\Program Files (x86)\Tweaking.com\Registry Backup\TweakingRegistryBackup.exe
Faulting module path: C:\WINDOWS\SYSTEM32\MSVBVM60.DLL
Report Id: 6b50db5c-33de-48da-9eb6-f3e412c3c5d8
Faulting package full name:
Faulting package-relative application ID:
This is the first, pristine, occurrence of the error, before I had tried any other DLL or OCX files.
By the way, putting DLL and similar files in the program directory is absolutely standard for debugging. In earlier versions of Windows it was necessary in production, where different programs required different, incompatible, DLLs - "DLL Hell"; later Windows versions have largely solved that problem with the WinSxS component store. I strongly recommend this instead of changing the DLL in its "official" location unless the change is meant to be permanent and for all applications: it avoids later problems with sfc and DISM. Microsoft document the search order for DLLs, and explicitly say "A system can contain multiple versions of the DLL":
https://msdn.microsoft.com/en-us/library/ms682586.aspx
While I'm out of date on debugging Windows, I have in the past written DLLs, debugged overlaid code for which I didn't have the source or symbols (very time-consuming), and placed DLLs in program directories a great many times, always successfully.
I've just rechecked, and the automatic registry backup still crashes (sometime these problems clear up with routine system updating and maintenance).
Thanks again
pol098:
--- Quote from: Julian on May 19, 2016, 01:17:41 pm ---place this dll in your c:\windows\syswow64 (for windows 64 bit) the syswow64 is where all 32bit dll goes
then run this in cmd (Make sure its an elevated cmd other wise you will get an error 800a0046)
cd \windows\syswow64
regsvr32 c:\windows\syswow64\MSVBVM60.DLL
let me know if you get a crash.
oh and please delete the dll in the rb program folder it should never be placed in there lol....
--- End quote ---
Thanks. Summary: the DLL version you attach is the one I was using when the problem first manifested, and I posted a detailed log in another thread at the time. So I had already done what you ask, described what happened, and posted the event log.
Detail: The file you attach, MSVBVM60.DLL 6.0.98.15 (thanks), is exactly the one that was on my Win10/64 machine when the problem first manifested (not just the same version number, byte-by-byte identical, same timestamp). As it happens, I posted exactly the information you request in another thread, before starting this one: the full event log for it (showing v6.9.98.15) is here:
http://www.tweaking.com/forums/index.php?topic=4281.5 Reply#5 of 19 April.
I copy the event log entry from that post:
Faulting application name: TweakingRegistryBackup.exe, version: 3.4.0.1, time stamp: 0x56f4a2b2
Faulting module name: MSVBVM60.DLL, version: 6.0.98.15, time stamp: 0x49b01fc3
Exception code: 0xc0000005
Fault offset: 0x000c9ba6
Faulting process id: 0x2040
Faulting application start time: 0x01d19a3622cb4882
Faulting application path: C:\Program Files (x86)\Tweaking.com\Registry Backup\TweakingRegistryBackup.exe
Faulting module path: C:\WINDOWS\SYSTEM32\MSVBVM60.DLL
Report Id: 6b50db5c-33de-48da-9eb6-f3e412c3c5d8
Faulting package full name:
Faulting package-relative application ID:
This is the first, pristine, occurrence of the error, before I had tried any other DLL or OCX files. It occurred on a laptop machine upgraded from Win7/64 to Win10/64; MSVBVM60.DLL 6.0.98.15, the exact one you supplied and with the same timestamp, was in the SysWow64 directory when the problem first manifested before I did anything.
I deliberately avoid changing system files if I can help it; it causes later trouble with sfc, DISM, and so on. It's absolutely standard practice to place DLLs and other files in the program directory to override those installed on the system; Microsoft say "A system can contain multiple versions of the same dynamic-link library (DLL)". The directory from which the application loaded is searched before any other. See
https://msdn.microsoft.com/en-us/library/ms682586.aspx
I'd add that the event log confirms after every crash that the DLL version found is the one in the program directory; e.g. if 6.0.98.32 is in the program directory and 6.0.98.15 in SysWow64, the event log reports 6.0.98.32
In earlier versions of Windows (before the WinSxS component store and sfc) it was usual to place DLLs used by a program in the program directory, to avoid invoking an incompatible version; I have done this, entirely successfully, scores of times. When writing a DLL I always put it into the program directory (as does everyone else, including tweaking.com!).
See DLL hell: https://en.wikipedia.org/wiki/DLL_Hell
Anyway, while trying to debug the backup problem I placed a number of versions of MSVBVM60.DLL (one at a time) and OCX files in the program directory. Unlike versions placed in system directories, simply deleting these versions (which I did immediately after testing) restored everything to EXACTLY how it was before.
The crash manifests in exactly the same way, at the same location in MSVBVM60.DLL (relative to exports, not absolute offset), for every DLL and OCX I tried, from Win98 to Win10 (they all worked fine for manual backup).
I'm not the only user to suffer this problem with registry backup; the exact same problem has been reported by others, with no resolution posted (search for MSVBVM60.DLL in this forum). What I don't know for sure is if it's universal with Win10/64; nobody has responded saying that it does work with Win10.
Thanks again
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version