Main Forum > Tweaking.com Support & Help
Registry backup crashes Win10, auto mode. MSVBVM60.DLL bug?
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:
--- Quote from: pol098 on May 16, 2016, 07:59:29 am --- 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.
--- End quote ---
Can you explain why you did this out of curiosity?
pol098:
--- Quote from: Julian on May 18, 2016, 11:15:19 pm ---
--- Quote from: pol098 on May 16, 2016, 07:59:29 am --- 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.
--- End quote ---
Can you explain why you did this out of curiosity?
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version