0

What is the registry subtree HKCR\VBKeySave5 for? Why does it have such a huge effect on VB6 IDE performance?

Background:

One of our development PCs (Windows 10 x64) had a very slowly loading VB6 IDE. The IDE was slow to load initially, and very slow to bring up the project references window. (Tens of seconds, or even ~minutes).

Purusing the registry for one of the libraries used by the project revealed the subtree HKCR\VBKeySave5. Under this subtree were thousands of entries that looked like the usual COM marshland of GUIDs, class IDs, classnames, etc. which you get with VB6 DLLs, etc.

Deleting this key and everything under it made the IDE perform immeasurably faster - basically it would load and then show the references window instantaneously.

Nothing bad seemed to happen as a result of this.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81

1 Answers1

7

It appears that the VBKeySave5\ subtree is used by the VB6 IDE when running with multiple projects in a group.

When running in the group, VB6 cleverly makes all the COM references that normally be served from a compiled DLL actually redirect to the IDE, so you can debug right into projects in the same group. It seems to use the VBKeySave5\ subtree to implement some of this wizardry.

I made a test project which contained one test DLL. Then made a test group containing both. Using Process Monitor I spied on what the IDE was doing in the registry. This is the basic sequence of events:

  1. Load project group
  2. Run project group - debugging begins
  3. IDE creates the VBKeySave5\ subtree
  4. IDE populates that subtree with a bunch of stuff
  5. Test program executes in the IDE / debugger
  6. Test program terminates
  7. IDE removes all the stuff under VBKeySave5\
  8. IDE returns to edit mode (debugging ends)

In that scenario, nothing extra is left in the registry.

Now - if after step 5 I killed the VB6.exe process, all the registry junk it added never gets removed. And running VB6 again and running the same group doesn't clean it up -- it just creates slightly different stuff under VBKeySave5\ instead.

So over time, especially with larger projects, cases when the IDE terminates abnormally add tons of useless clutter to the registry. And it appears this clutter still has to be read through by the IDE when it loads the project, etc. slowing it way down.

In our case, for whatever reason the IDE crashes a lot. And we use project groups (with 4, 5, 6 projects) regularly. So it appears that these crashes junk up VBKeySave5\ with lots of entries, and that causes the slowdown.

Maybe there are also situations other than crashes where VB6 doesn't clean up after itself.

Additional information related to why VBKeySave5 might not be cleaned up automatically:

The VS Installer for Windows 10 allows you to set the VB6.EXE compatibility mode to Windows Vista (Service Pack 2).

DO NOT DO THIS.

Do not run the VB6 IDE in compatibility mode of any kind. The suggested purpose is to fix anomalies in the graphic designer of the IDE. Believe me, these anomalies are nothing compared to the damage left in your windows registry when VB6.EXE is run in compatibility mode.

When VB6.EXE is used to Compile-And-Run your application, it replaces GUIDs and class and typelib registrations causing them to refer to its VB6DEBUG.DLL. this allows the IDE to intercept execution of your code so you can debug. When it does this replacement of your DLL and OCX registrations, it saves your stuff under HKCR\VBKeySave5. Unfortunately, when VB6.EXE is set to run in compatibility mode of an earlier verison of Windows, it fails to restore all of your DLL and OCX registration information. It leaves VBKeySave5 there, which causes your IDE to take much longer during subsequent starts of the IDE, and it trashes your registry, eventually rendering your application not-runnable on your machine.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81