Voodoo COM Interop

It is unlikely, but non entirely impossible. You might have a VB6 app using the fine, open sourced vbAccelerator controls. You might have a Rebar control, a few Toolbarcontrols, and a Popupmenu control, to overcome the limitations of the obsolete VB6 standard controls.
And everything would seem to work just fine: a workaround to overcome GPF on exit (attributed to a COMCTRL32.DLL bug) is in place, but it works flawlessly. One day, you might start to use .NET modules with COM Interop. In the IDE, everything would still works just fine, but outside it… a GPF on exit. Only when the COM Interop modules are called. And only from VB6 consumers with the vbaccelerator controls.
You might solve the mistery, at the expense of a mild case of sleep deprivation. But not if you’re reading this, because the culprit is the lack of the .RemoveAllRebarBands method from the vbAccelerator Rebar Control. Yes, the good working sample code doesn’t use it and specifically states it isn’t needed. And it isn’t, but only up to a particular level of rebar crowding.Yes, it doesn’t particularly make sense, but it works.

How is it feasible to finally solve, practically and without spending days or weeks, these nasty problems? vbAccelerator components are fine, but, being legacy code to say the least, there isn’t much support or discussion space around. Com Interop is not particularly well covered or supported by MS (event though it works, and it’s a lifesaver in the real world). You go by exclusion: I found out that a VB6 consumer without those controls worked just fine, and I started disabling code in the othe consumer, until the problem stopped appearing. At that point, I had identified the problem in the Rebar area: I started moving switches and changing properties and method around, until I hit the RemoveAllRebarBands.  Not very orthodox, but probably quicker than debugging everything at a low level..