Registry backup crashes Win10, auto mode. MSVBVM60.DLL bug?

[pol098]

Re: Tweaking Registry Backup crashing, MSVBVM60.DLL faults

I'm repeating something I posted in an existing thread last month.
http://www.tweaking.com/forums/index.php/topic,4281.msg32230.html#msg32230 ,
just in case it got missed there (although I had some responses).

I've been having a problem that others have reported (search the forum for MSVBVM60) with Registry Backup. I had been using ERUNT, successfully, under Win 7 (it didn't back up the Components hive, but I was OK without it), but it didn't behave well under Win 10 so I installed RB. Win 10/64, up-to-date as of now, current RB 3.4.0.1. As it wasn't working I changed the VSS executable from automatic to vss_7_8_2008_2012_64.exe, same behaviour.

I have set up RB to run as System on login of any user, saving to a non-standard location and not more than once per day. The VSS service was initially set to run manually, but I changed it to automatic. RB runs fine manually, but does not back up automatically. I looked at the event log and found Error, event ID 1000. Details:

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:

MSVBVM60.DLL is a Visual Basic Virtual Machine. On running manually a shadow copy is created, with a progress indicator; the automatic invocation doesn't seem to have created a shadow copy. It doesn't seem to be a timing issue, with the VSS service not being ready at login time: RegisrtyBackup be default sets up Task Scheduler to delay 5' after login. I don't know if Microsoft provide debugging maps and so on to pin down the MSVBVM60.DLL error.

My machine is a modern laptop sold as suitable for games, has 8GB of RAM and a 4-core 2.5GHz Intel i7 CPU, though using Intel 4600 on-chip graphics instead of a high-performance card, and the backup works perfectly if started manually, so I don't think performance is an issue.

This may well be a program problem that needs addressing; I'm not the only one to report this issue (see
http://www.tweaking.com/forums/index.php?topic=4033.0 )
Does RB make any calls to the Visual Basic Virtual Machine DLL MSVBVM60.DLL in automatic mode that it doesn't make in manual mode? The Event Viewer error message gives a specific exception 0xc0000005 - an access violation - in that module, at 0x000c9ba6.

ADDED LATER: there are many reports of problems and crashes with MSVBVM60.DLL (plus a lot of rubbish sites found by Google). One suggested action that was reported to work for some, but not all, people in 2010 (pre-Win10) was to use an earlier MSVBVM60.DLL from WinXP. I haven't yet followed this up. All the versions of this file that I've found, back to Win98, seem to be about the same size (rounding to 1.32MB), so maybe it hasn't been changed much.

I can't comment on the Registry Backup program and haven't yet tried to restore a backup; if it ultimately works as well as ERUNT did under Win7 I'll be happy. A suggestion I'd make is an option to use "20160510" (or 160510) in file/directory names instead of "10May16", as this form sorts alphanumerically in chronological order. I set ERUNT up to iuse this (not the default), and it's helpful.

Best wishes, pol098

[pol098]

Following up to my previous post (nothing new, just unsuccessful debugging), I've checked all files associated with the MSVBVM60 (Microsoft Visual Basic Virtual Machine 6.0). My up-to-date Win10/64 machine had six OCX files (from about 2004) that had been superseded by 2010 versions: comct232.ocx, comctl32.ocx, comdlg32.ocx, mscomctl.ocx, MSFLXGRD.ocx, tabctl32.ocx (the Win10 update doesn't touch these files). The old files were in c:\Windows\SysWOW64\; I overwrote them with the new ones, and also copied the new ones them into the program directory. The VM6 update files, while including several DLLs and other OCXs, didn't have newer versions of any files existing on the Win7/64 system. No change: program still fails when run automatically at logon, still succeeds when invoked manually. The backup directory is owned by Administrator; both Administrators and SYSTEM have full access (unchanged). This is just a no-progress report. Best wishes

[Julian]

Huh im gonna test this on my windows 10 vm and see if I can duplicate this.

[pol098]

Following up with a bit more (negative) information: additional to everything else, I placed MSVBVM60.DLL version 6.0.98.32 (the latest I could find, 1,426,944 bytes, modified 03 ‎April ‎2011, ‏‎02:26:10) in the c:\Program Files (x86)\Tweaking.com\Registry Backup\ directory. It failed in the same way as before in automatic mode, and succeeded as before invoked manually. the event  log entry confirmed that the error occurred in the DLL in the program file, not the original, lower-numbered one that came with Win10. Apart from systematically going through other versions of MSVBVM60.DLL (there have been suggestions that some versions have this sort of bug), I'm out of ideas.

Event log is consistent with the one detailed in a previous post; same Exception code: 0xc0000005 (access violation), location a bit later. Googling <Exception code: 0xc0000005 MSVBVM60.DLL> finds lots of hits.

The machine in general works flawlessly. sfc finds nothing.

Similar issue in Windows Repair:
http://www.tweaking.com/forums/index.php/topic,1619.0/nowap.html

Additional information, report.wer from latest occurrence (today):
Version=1
EventType=APPCRASH
EventTime=131076297106985646
ReportType=2
Consent=1
UploadTime=131076297108548276
ReportIdentifier=dd05f06e-1925-11e6-be0a-80fa5b10fd00
IntegratorReportIdentifier=9bdd3438-a794-4110-972b-06e380034fe5
WOW64=1
NsAppName=TweakingRegistryBackup.exe
Response.BucketId=fa8fce85721c9b478156bc32db31e42b
Response.BucketTable=1
Response.LegacyBucketId=108064292809
Response.type=4
Sig[0].Name=Application Name
Sig[0].Value=TweakingRegistryBackup.exe
Sig[1].Name=Application Version
Sig[1].Value=3.4.0.1
Sig[2].Name=Application Timestamp
Sig[2].Value=56f4a2b2
Sig[3].Name=Fault Module Name
Sig[3].Value=MSVBVM60.DLL
Sig[4].Name=Fault Module Version
Sig[4].Value=6.0.98.32
Sig[5].Name=Fault Module Timestamp
Sig[5].Value=4eb1c425
Sig[6].Name=Exception Code
Sig[6].Value=c0000005
Sig[7].Name=Exception Offset
Sig[7].Value=000e600f
DynamicSig[1].Name=OS Version
DynamicSig[1].Value=10.0.10586.2.0.0.256.48
DynamicSig[2].Name=Locale ID
DynamicSig[2].Value=2057
DynamicSig[22].Name=Additional Information 1
DynamicSig[22].Value=bfff
DynamicSig[23].Name=Additional Information 2
DynamicSig[23].Value=bfff67c04b3b425f80e6df640b8c2926
DynamicSig[24].Name=Additional Information 3
DynamicSig[24].Value=2944
DynamicSig[25].Name=Additional Information 4
DynamicSig[25].Value=29445af5e8fefb6667ccbdbe9dc6b028
UI[2]=C:\Program Files (x86)\Tweaking.com\Registry Backup\TweakingRegistryBackup.exe
UI[5]=Check online for a solution (recommended)
UI[6]=Check for a solution later (recommended)
UI[7]=Close
UI[8]=Tweaking.com - Registry Backup stopped working and was closed
UI[9]=A problem caused the application to stop working correctly. Windows will notify you if a solution is available.
UI[10]=&Close
LoadedModule[0]=C:\Program Files (x86)\Tweaking.com\Registry Backup\TweakingRegistryBackup.exe
LoadedModule[1]=C:\WINDOWS\SYSTEM32\ntdll.dll
LoadedModule[2]=C:\WINDOWS\SYSTEM32\KERNEL32.DLL
LoadedModule[3]=C:\WINDOWS\SYSTEM32\KERNELBASE.dll
LoadedModule[4]=C:\Program Files (x86)\Tweaking.com\Registry Backup\MSVBVM60.DLL
LoadedModule[5]=C:\WINDOWS\SYSTEM32\USER32.dll
LoadedModule[6]=C:\WINDOWS\SYSTEM32\GDI32.dll
LoadedModule[7]=C:\WINDOWS\SYSTEM32\ADVAPI32.dll
LoadedModule[8]=C:\WINDOWS\SYSTEM32\msvcrt.dll
LoadedModule[9]=C:\WINDOWS\SYSTEM32\sechost.dll
LoadedModule[10]=C:\WINDOWS\SYSTEM32\RPCRT4.dll
LoadedModule[11]=C:\WINDOWS\SYSTEM32\SspiCli.dll
LoadedModule[12]=C:\WINDOWS\SYSTEM32\CRYPTBASE.dll
LoadedModule[13]=C:\WINDOWS\SYSTEM32\bcryptPrimitives.dll
LoadedModule[14]=C:\WINDOWS\SYSTEM32\ole32.dll
LoadedModule[15]=C:\WINDOWS\SYSTEM32\combase.dll
LoadedModule[16]=C:\WINDOWS\SYSTEM32\OLEAUT32.dll
LoadedModule[17]=C:\WINDOWS\SYSTEM32\kernel.appcore.dll
LoadedModule[18]=C:\WINDOWS\SYSTEM32\SXS.DLL
LoadedModule[19]=C:\WINDOWS\SYSTEM32\clbcatq.dll
LoadedModule[20]=C:\WINDOWS\SYSTEM32\coml2.dll
LoadedModule[21]=C:\Program Files (x86)\Tweaking.com\Registry Backup\Codejock.Controls.Unicode.v17.1.0.ocx
LoadedModule[22]=C:\WINDOWS\SYSTEM32\SHELL32.dll
LoadedModule[23]=C:\WINDOWS\SYSTEM32\MFC42u.DLL
LoadedModule[24]=C:\WINDOWS\SYSTEM32\cfgmgr32.dll
LoadedModule[25]=C:\WINDOWS\SYSTEM32\windows.storage.dll
LoadedModule[26]=C:\WINDOWS\SYSTEM32\shlwapi.dll
LoadedModule[27]=C:\WINDOWS\SYSTEM32\shcore.dll
LoadedModule[28]=C:\WINDOWS\SYSTEM32\powrprof.dll
LoadedModule[29]=C:\WINDOWS\SYSTEM32\profapi.dll
LoadedModule[30]=C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.10586.0_none_811bc0006c44242b\COMCTL32.dll
LoadedModule[31]=C:\WINDOWS\SYSTEM32\OLEPRO32.DLL
LoadedModule[32]=C:\WINDOWS\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.10586.20_none_22adb5eaa762c7fa\gdiplus.dll
LoadedModule[33]=C:\WINDOWS\SYSTEM32\ODBC32.dll
LoadedModule[34]=C:\WINDOWS\SYSTEM32\DPAPI.dll
LoadedModule[35]=C:\WINDOWS\SYSTEM32\UXTHEME.DLL
LoadedModule[36]=C:\Program Files (x86)\Tweaking.com\Registry Backup\TweakingImgCtl.ocx
LoadedModule[37]=C:\WINDOWS\SYSTEM32\WindowsCodecs.dll
LoadedModule[38]=C:\WINDOWS\system32\dataexchange.dll
LoadedModule[39]=C:\WINDOWS\system32\dcomp.dll
LoadedModule[40]=C:\WINDOWS\system32\d3d11.dll
LoadedModule[41]=C:\WINDOWS\system32\dxgi.dll
LoadedModule[42]=C:\WINDOWS\system32\twinapi.appcore.dll
LoadedModule[43]=C:\WINDOWS\system32\bcrypt.dll
LoadedModule[44]=C:\WINDOWS\SYSTEM32\DWrite.dll
LoadedModule[45]=C:\Program Files (x86)\Tweaking.com\Registry Backup\Tweaking_Tabsv2.ocx
LoadedModule[46]=C:\Program Files (x86)\Tweaking.com\Registry Backup\SSubTmr6.dll
LoadedModule[47]=C:\Program Files (x86)\Tweaking.com\Registry Backup\MSINET.OCX
LoadedModule[48]=C:\WINDOWS\SYSTEM32\WININET.dll
LoadedModule[49]=C:\WINDOWS\SYSTEM32\msimg32.dll
LoadedModule[50]=C:\Program Files (x86)\Tweaking.com\Registry Backup\pcwintech_tasksch.dll
LoadedModule[51]=C:\WINDOWS\System32\mstask.dll
LoadedModule[52]=C:\Windows\SYSTEM32\scrrun.dll
LoadedModule[53]=C:\Windows\SYSTEM32\VERSION.dll
LoadedModule[54]=C:\WINDOWS\System32\msxml3.dll
State[0].Key=Transport.DoneStage1
State[0].Value=1
FriendlyEventName=Stopped working
ConsentKey=APPCRASH
AppName=Tweaking.com - Registry Backup
AppPath=C:\Program Files (x86)\Tweaking.com\Registry Backup\TweakingRegistryBackup.exe
NsPartner=windows
NsGroup=windows8
ApplicationIdentity=01CD94E81CDEFEC0C6D74F5AA290B734

 Best wishes, pol098

[pol098]

Update of non-progress: from reports I found on the Web I suspected an error in some versions of MSVBVM60.DLL. This doesn't seem to be the case; I've placed versions 6.0.97.82, 6.0.98.15, 6.0.98.21, 6.0.98.31, and 6.0.98.32 (date ranging from 2004 to 2012) in the RegistryBackup program directory. In all cases the automatic backup fails with the same exception (and the event log confirms that the failing version is the one I'm testing, it's not a case of finding the wrong DLL); and the manual backup succeeds. HTH

Clarification added 19My16: I added one of the DLL versions listed to the program directory and rebooted to see if the backup succeeded. I repeated this with each of the others. There was (obviously, they have the same name) only one "c:\Program Files (x86)\Tweaking.com\Registry Backup\msvbvm60.dll" at any one time.

[Julian]

Try closing the tray icon see what happens.

[pol098]

"Try closing the tray icon see what happens."

Thanks. I'm running as system, I don't even have an option to have a tray icon (and no actual tray icon). I've investigated further, and will post my results as a new message.

[pol098]

Continuing with the issue I started the thread with: I have some actual information about the crash in MSVBVM60.DLL, though no solution. I think a post in another thread found another tweaking.com program with a similar problem to the registry backer-up in MSVBVM60.DLL; there may be some common behaviour in the tweaking.com programs.

I've looked at the crash location in MSVBVM60.DLL with the Windows event viewer, for 6 versions of the DLL. I've also looked at the functions exported by the DLL. Assuming that the relative addresses in the function list correspond to the location shown in event viewer, in all 6 versions of MSVBVM60.DLL the crash occurs 12 bytes after the offset of exported EVENT_SINK2_AddRef, ordinal 440=0x1b8, and before the next exported offset. So possibly the crash is related to this function?

My raw data follows. First column is MSVBVM60.DLL version; col. 2 is crash location from event viewer; col. 3 is address of start of export EVENT_SINK2_AddRef from a list of exports.

6.0.97.82 c9ac6 c9aba
6.0.98.15 c9ba6 c9b9a
6.0.98.21 c9aec c9ae0
6.0.98.31 c9b4b c9b3f
6.0.98.32 e600f e6003

By the way, all versions of MSVBVM60.DLL tested except 6.0.98.32 (larger) are exactly 1,386,496 bytes; they are padded at the end with different quantities of NULs. v6.0.98.32 has non-NUL values after the 1,386,496 byte mark; it just won't fir in this size. Remark out of curiosity, doesn't seem relevant to this problem.

Just out of caution after problems in the past, I've changed the drive for VSS from B: (default; 2nd floppy drive?) to X:; and the name from "Auto Backup" or whatever it was to "AutoRegback" (no spaces). I haven't tested the effect yet, but have no expectations.

Best wishes

[Julian]

I've placed versions 6.0.97.82, 6.0.98.15, 6.0.98.21, 6.0.98.31, and 6.0.98.32 (date ranging from 2004 to 2012) in the RegistryBackup program directory.

Can you explain why you did this out of curiosity?

[pol098]

I've placed versions 6.0.97.82, 6.0.98.15, 6.0.98.21, 6.0.98.31, and 6.0.98.32 (date ranging from 2004 to 2012) in the RegistryBackup program directory.

Can you explain why you did this out of curiosity?

I think you're asking this because my original posting was unclear (I'll edit the original for anyone who comes here via a search). I put these versions of MSVBVM60.DLL in the RegistryBackup program directory one at a time, rebooting the machine each time, after seeing reports in (non-tweaking.,com) forums of crashes cured by changing the version used. When a DLL of the same name is both in a system directory and the directory of a program under test, the (default) system one is overridden; in my tests this was confirmed by checking the version where the event log reported the error. With any one of these versions in the program directory a crash was reported at what seems to be the same exported function of MSVBVM60.DLL. I hope this clears up any misunderstanding, and explains my (standard) debugging technique. Best wishes

[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]

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?

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]

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....

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]

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....

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

[Julian]

Ran it on my windows 10 no problem did not get the crash. Hmm

[pol098]

Ran it on my windows 10 no problem did not get the crash. Hmm

Thanks for that information, very useful: the program is known to work properly under Win10. Armed with this fact, I deleted the scheduled task, uninstalled and reinstalled RegistryBackup, leaving all settings at default; it now created backup files, unlike before. I then changed all my settings, one by one, back the way I had them before, and it continued to work. Best guess is a permissions issue with SYSTEM writing the backup, although the logged-in user could back up. I did ensure that SYSTEM had Full control of the backup directory, but possibly something went wrong there.

I should have done the clean reinstall before, but was sidetracked by the MSVBVM60.DLL crash, thinking that it was the problem. It's actually unrelated: with RegistryBackup seeming to work the MSVBVM60.DLL crash still occurs in exactly the same way according to the event log. It is probably an event without consequences, but a little disturbing. The backup creates files of the expected size, while before it didn't, though I haven't tested them yet.

Could I ask if others find the crash in MSVBVM60.DLL after an apparently successful backup?
(Event viewer > Custom Views > Administrative Events > right-click > Find, type MSVBVM60)

Otherwise the backup seems to be working now. Many thanks for help.

[Julian]

I don't see why not .