VB6 SP6 Security Update Dec 9, 2008

This week Microsoft released an update that addresses a security issue in several controls:

Microsoft Visual Basic 6.0 Service Pack 6 Security Rollup Update

You can find a description of this update at:

MS08-070: Description of the security update for Microsoft Visual Basic 6.0 Service Pack 6 Runtime Extended Files: December 9, 2008

Note that the update can result in a design-time issue relating to the Winsock control. See:

Error message when you right-click the Mswinsck.ocx ActiveX control (Winsock Control) after you install security update KB926857

This update may require that you first upgrade to VB6 SP6. Since it requires Windows Installer 3.1 or later you must be on Windows 2000 SP3 or later, and may have to first install:

Windows Installer 3.1 Redistributable (v2)


On the plus side: These controls may contain other fixes in addition to the security patches.

On the minus side: This update cannot be uninstalled. You might want to test with it on a separate system (or a VM you can roll back).


Has anyone completed testing of this update yet?


Edit:

Please read the whole thread before acting on this update. Then consider it carefully (or its alternatives) before proceeding!

By all mean I would recommend to stay away from this update - not only it is pointless it already addresses "Known issues" like "Out of memory" (I think this one is winsock specific).
I personally am happy with SP4.

But between SP4 and SP6 there were many bugs fixed in many controls. In particular the Winsock control can be almost worthless until SP6.

Here are just the SP6 fixes: List of bugs that are fixed in Visual Studio 6.0 Service Pack 6.

Here are the SP5 fixes: List of Bugs Fixed in Visual Studio 6.0 Service Pack 5.

It also looks like the security vulnerabilities this Update fixes have been there for a long time, so staying with SP4 means you're potentially shipping your users security vulnerabilities. I agree with caution and testing first though.

Microsoft Security Bulletin MS08-070 - Critical

Quote:

---

This security update is rated Critical for supported components of the Microsoft Visual Basic 6.0 Runtime Extended Files; all supported editions of Microsoft Visual Studio .NET 2002, Microsoft Visual Studio .NET 2003, Microsoft Visual FoxPro 8.0, Microsoft Visual FoxPro 9.0, Microsoft Office Project 2003, Microsoft Office Project 2007; and the Chinese Simplified (China), Chinese Pan (Hong Kong), Chinese Traditional (Taiwan), and Korean versions of Microsoft Office FrontPage 2002. For more information, see the subsection, Affected and Non-Affected Software, in this section.

---

And all along I have though that support for our good old VB6.0 has ended?

They'll still issue patches for critical security problems and anything else they "feel like."

I assume they only "feel like it" when they get enough paid support incidents on an issue and they have a good fix, or when a new OS breaks something.

Here's an earlier one that trips people up:

MS07-043: Description of security update for the Visual Basic 6.0 redistributable

Quote:

---

What these changes mean for software vendors who package and redistribute the Oleaut32.dll file together with an application

The change in how the Oleaut32.dll file is shipped has the following results. If you are a software vendor who packages and redistributes the Oleaut32.dll file in an application, you cannot ship a single file for all the destination operating systems on which the application runs. Instead, you must ship the version of the Oleaut32.dll file that is appropriate for the particular operating system on which the package will be installed.

Note We recommend that you do not select only the copy of the Oleaut32.dll file that is located in the %WINDIR%\System32 folder. We recommend this because the version that is located in this folder has been tested for use only with the particular operating system.

For example, if you use a Windows XP-based computer to develop and package the application, and if you select the copy of the Oleaut32.dll file that is located in the %WINDIR% \System32 folder on this computer, the application will not run on any operating system other than Windows XP. For example, the application will not run on a Windows Server 2003-based computer.

---

People who fail to do this are either reinstalling an insecure older version to users' systems or breaking all VB6 applications on those users' systems with a different OS. Even if you did not realize it, Windows Update may have installed an OS-specific version of Oleaut32.dll on your dev machine as part of routine patching. This is why you are never supposed to package from your System32 folder, and why PDW has its redist folder which it will use first when looking for libraries to package.


Download:

Visual Basic 6 OLEAUT32.DLL Security Update


This relates to the same fix, re-released:

MS08-008: Description of the security update for Microsoft Visual Basic 6.0: February 12, 2008

Quote:

---

Originally Posted by dilettante

But between SP4 and SP6 there were many bugs fixed in many controls...

---

I'm yet to come across any so personally I could care less for anything above SP4. More - SP5 and SP6 created more problem than they fixed.

Quote:

---

Originally Posted by dilettante

...In particular the Winsock control can be almost worthless until SP6....

---

Not quite true - I've used it without any problems what so ever.

I'd love to hear about any problems the later service packs caused. The only one I'm aware of is one in the earliest SP6 release, that was fixed shortly thereafter.

How about IDE constantly crashing, inconsistent debugger, memory leaks, etc... "Degrading" it back to SP4 fixed the issues. Wouldn't that be enough?

Quote:

---

Originally Posted by RhinoBull

How about IDE constantly crashing, inconsistent debugger, memory leaks, etc... "Degrading" it back to SP4 fixed the issues. Wouldn't that be enough?

---

I'm using sp6 and can't say I've had any of those problems.

Environments vary I guess...

Quote:

---

Originally Posted by longwolf

I'm using sp6 and can't say I've had any of those problems.

---

I'm using SP5, and have had intermittent crashes of the IDE. For example,
the app is running, I'm at a breakpoint, I alter some code, and then resume
the app. 99% of the time, this works fine.

But that nasty 1% -- the IDE window closes, and I get one of those
dreaded "Do you want to report..." dialogue boxes. All changes made are
lost. So, I now save frequently !!

Plus periodically, following some "at breakpoint" editting, variables return
screwy results. Solution: save the app, exit VB6 altogether, relaunch VB6,
and the screwy results are now gone.

I can't recall if the above started happening when I upgraded from SP4 ..
indeed, can't even recall if I ever did !! (may have come with the computer
when I bought it).

Spoo

Spoo, have you tried SP6? longwolf is using SP6 so you can't compare the two.

I use Winsock most of the time, with my projects. I am using VB6 Pro SP6 already, and I am not finding anything wrong with it. Not saying that there is anything wrong with it, anyway.

dee-u

Yes, you are correct, comparison may be inaccurate, and no, I
haven't tried SP6 yet -- mainly: inertia. I've gotten used to SP5's
idiosyncracies. Some day ...

Spoo

Mircosoft soon will cut the usage of Visual Basic 6.00, all versions of it as well. Also they are wiping out the run-time files out of the next operating system, I have heard.

Soyou better make it up really soon, in deed!!

Been using sp6 for at least 3 yrs on w2k and xp and have none of the problems mentioned

I may not use this secruity upgrade, because it doesn't take my programming project into account. Therefore I won't do it. Next SP7? Maybe?

Dear all,

I maintain a VB6 application including MSCharts controls, working well with
my old ocx file (mschrt20.ocx V6.00.88.4, March 14th 2000).
In my company, an upgrade was done on the operating system and this
file was upgraded to V 6.1.98.12 and the application becomes unstable
(apparently, all old VB6 applications suffer from this upgrade and not only
regarding MSChart controls).

For instance in my application I have a line coded this way:

With MSChart.Plot.Backdrop
...
End With

With the new control the application gets an error on the With line
with description "bad function argument". On some other pieces of codes the
application crashes completely, like for instance on a line of type:

Me.frm_MyFrame.Visible = True

where Me is a VB.Form and frm_MyFrame is a VB.Frame
(I checked by editing the .frm file ), BUT the bug displayed is: Visual Basic

Error Signature --------------------------------------------------------

AppName vb6.exe AppVer 6.0.81.76 ModName: mschrt20.ocx

ModVer: 6.1.98.12 Offset 000644ba

Followed by a typical message "The instruction at.... referenced memory .... at. The memory could not be read. Click OK to terminate the program"

(Actually the crash only occurs on a frame that contains an MSChart control, not the others..)

The origin of the problem seems to be a security update of microsoft:

http://support.microsoft.com/kb/932349/en-us
(critical security update MS08-070 )

Did anybody get a similar problem with this patch?
Any idea if there is a fix to this major regression??

Thanks and best regards,

Eric

Have you considered the workaround suggested for VBA in that KB article? It might roll back the control updates.

Quote:

---

To resolve this issue, install the cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files update. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

957924 (http://support.microsoft.com/kb/957924/ ) Description of the cumulative update rollup for the Visual Basic 6.0 Service Pack 6 Runtime Extended Files.

---

I have to say the handling of this matter by Microsoft truly stinks. If they know about flaws and exactly what is wrong they should have reposted a corrected Update package. For example:

http://support.microsoft.com/kb/960128/

Quote:

---

This error is caused by an array index off-by-one bug that occurs while the properties of the control are being fetched.

---

Ahh, perhaps the item I linked above (http://support.microsoft.com/kb/957924/) which is dated Dec 30, 2008 does indeed address the known issues:

Quote:

---

Microsoft has released a cumulative update rollup for the Microsoft Visual Basic 6.0 Service Pack 6 (SP6) Runtime Extended Files. This cumulative update rollup includes security update 926857 and updated versions of many other Microsoft ActiveX controls that make up the Visual Basic 6.0 Runtime Extended Files.

---

This installs version 6.1.98.13 controls. It may not install into any OS prior to XP SP2, but you can always try.

Thanks for your reply dilettante,

I have forwarded your answer to the team in charge of maintaining
the OS. sounds interesting... I will let you know if it solves
my issue.

Best regards,

Eric

Best of luck!

I'm wary of installing either Update on a production or dev machine at this point. I'll have to give it a go in a VM after I install VB6 into one, though I hesitate to think how involved testing will have to be before I'm comfortable.

If only these things could be rolled back in case of problems... but the cautions in those KB articles suggest otherwise.

Dear dilettante,

I can confirm that the microsoft update of december 30th does
not fix the bug in MSChart controls... :-(

Thanks anyway for your help!

best regards,

Eric

Have you considered that VB6.exe 6.0.81.76 is extremely ancient (dating near September 2000, maybe SP2 or SP3)?

Those Updates assume VB6 SP6 compiler and runtimes.

I created a test case here with an MSChart20 control on a VB6 Frame control on a VB6 Form. The Frame starts out as Visible = False.

There is a Command button that when clicked sets Frame1.Visible = True.

It seems to be working fine when I deploy this compiled program along with MSChart20.ocx version 6.1.98.13 (no problems at all). However I have not installed the Update into a development machine yet to see what it might do while testing within the IDE.

Maybe my test case is not complete enough to catch the problem?

Thread Stuck

Good content all should be aware of :)

Last Review: December 30, 2008 - Revision: 2.0

Microsoft has released a cumulative update rollup for the Microsoft Visual Basic 6.0 Service Pack 6 (SP6) Runtime Extended Files.
This cumulative update rollup includes security update 926857 and updated versions of many other Microsoft ActiveX controls that make up the Visual Basic 6.0 Runtime Extended Files.

http://support.microsoft.com/kb/957924/

Dear Edgemeal,

As I told to dilettante, this more recent update does not fix the problem
(it was tested by the team maintaining the OS). Actually
I'm working in a bank and the O/S is basically XP Pro 2002 Sp2, customized
by the O/S team for security purposes. So, even though microsoft patches
are applies with no modifications, I can't completely forget the possibility that the customization is responsible for the bug.
Anyway, a simple way to reproduce my problem is the following. Put a MSChart control and a command button
in a VB form, and paste the below code. With the latest ocx, when
clicking on the button the application crashes before the end, the
error is not trapped by the VB runtime. With the old one I can get
the message at the end.

Best regards,
Eric

Code:

---

Private Sub Command1_Click()
    InitializeMSChartAA Me.MSChart
    MsgBox "Test done!"
End Sub

Public Sub InitializeMSChartAA(MSChart As MSChart)
Dim serX As Object
Dim index1 As Integer
Dim index2 As Integer
Dim index3 As Integer
Dim index4 As Integer
Dim ArraySeriesColor As Variant
Dim i As Integer

On Error GoTo EH

ReDim ArraySeriesColor(4)

    With MSChart
        .AllowDynamicRotation = False
        .AllowSelections = True
        .AllowSeriesSelection = False
    End With
 
    MSChart.Title.Location.Visible = False
   
    Select Case MSChart.chartType
        Case VtChChartType2dPie
            MSChart.chartType = VtChChartType2dBar
        Case Else
    End Select
   
    If MSChart.Title.Location.Visible Then
        With MSChart.Title.VtFont
            .Name = "Algerian"
            .Style = VtFontStyleBold
            .Effect = VtFontEffectUnderline
            .Size = 14
            .VtColor.Set 255, 0, 255
        End With
    End If

    With MSChart.Plot
        .AutoLayout = False
        .LocationRect.Min.X = 0
        .LocationRect.Min.Y = 0
        .LocationRect.Max.X = MSChart.Width - 700
        .LocationRect.Max.Y = MSChart.Height         
        .Wall.Brush.Style = VtBrushStyleNull
        .Wall.Pen.Style = VtPenStyleNull
    End With

    MSChart.ShowLegend = True
   
    If MSChart.ShowLegend Then
        With MSChart.Legend
            .VtFont.Size = 7
            .Location.LocationType = VtChLocationTypeCustom
            .Location.Rect.Max.Set MSChart.Width * 1.74, MSChart.Height
            .Location.Rect.Min.Set 0, 0
            .VtFont.Name = "Tahoma"
        End With
    End If

    For i% = 0 To MSChart.Plot.SeriesCollection.Count - 1
   
        Set serX = MSChart.Plot.SeriesCollection.Item(i% + 1)
   
        If serX.LegendText <> "% of NAV" Then
                   
          serX.DataPoints.Item(-1).DataPointLabel.LocationType = VtChLabelLocationTypeAbovePoint
          serX.DataPoints.Item(-1).DataPointLabel.VtFont.Size = 7.5
          serX.DataPoints.Item(-1).DataPointLabel.Component = VtChLabelComponentValue
          serX.DataPoints.Item(-1).DataPointLabel.ValueFormat = "0" & "," & "0%"
          serX.DataPoints(-1).Brush.FillColor.Set 0, 0, 0
          serX.DataPoints(-1).EdgePen.VtColor.Set 0, 0, 0
        End If
    Next
    Set serX = Nothing
   
    With MSChart.Plot.Axis(VtChAxisIdX)
        .AxisGrid.MajorPen.Style = VtPenStyleNull
    End With
       
    With MSChart.Plot.Axis(VtChAxisIdY)
        .AxisGrid.MajorPen.Style = VtPenStyleNull
    End With
   
    With MSChart.Plot.Axis(VtChAxisIdY2)
        .AxisGrid.MajorPen.Style = VtPenStyleNull
    End With
   

    With MSChart.Plot.Axis(VtChAxisIdX).AxisScale
        .Hide = True
    End With

    With MSChart.Plot.Axis(VtChAxisIdY).AxisScale
        .Hide = True
    End With
 
    MSChart.Plot.Axis(VtChAxisIdY).ValueScale.Auto = False
   
    With MSChart.Plot.Axis(VtChAxisIdY2).AxisScale
        .Hide = True
    End With

GetOut:
    On Error Resume Next
    Exit Sub
   
EH:
 
    MsgBox Err.Description
   
End Sub

---

Dear All,

Just to confirm that on a dev environment fully patched with
VB6 Sp6 of the runtime, the problem is still there.

Best regards,

Eric Chopin

Hi again.

In the above example, the code can be reduced to:

Private Sub Command1_Click()
InitializeMSChartAA Me.MSChart
MsgBox "Test done!"
End Sub

Public Sub InitializeMSChartAA(MSChart As MSChart)
Dim serX As Object
On Error GoTo EH
Set serX = MSChart.Plot.SeriesCollection.Item(1)
serX.DataPoints.Item(-1).DataPointLabel.LocationType = VtChLabelLocationTypeAbovePoint 'VtChLabelLocationTypeInside
serX.DataPoints.Item(-1).DataPointLabel.ValueFormat = "0" & "," & "0%"
Set serX = Nothing
GetOut:
On Error Resume Next
Exit Sub

EH:
MsgBox Err.Description
End Sub


the line on which the application crashes is:
serX.DataPoints.Item(-1).DataPointLabel.ValueFormat = "0" & "," & "0%"

Commenting this line OR the previous one make the application work.

best regards,

Eric

Using the code from post #29 above I can confirm a failure using MSChart ver. 6.1.98.13 and the exception logged was 0xc0000005 (Access Violation Error).

I even tried turning off DEP for my compiled EXE and the failure still occurs.

I cannot think of a temporary resolution to this since Microsoft says the Update can't be uninstalled... aside from going to impacted machines and copying over the .OCX with the version prior to the Dec. 9, 2008 Update. ;)

Has anyone actually tried to uninstall these bad Update packages? That is, anyone else who has dared to install them in the first place?

I'd like to assume that they'll issue a tested fix, for this fix to the fix... before too long. With VB6's support status I'm not sure how soon that will be. Until someone forces a support incident through perhaps nothing will happen.

Yet they did take a second stab at the problem with that December 30 attempt.

For anyone in doubt, the -1 in the example is correct:

Quote:

---

DataPoint

Remarks

The DataPoints collection is accessed through the SeriesCollection object.

Important The DataPoints collection contains only one member at this time. To access it, you must use the –1, as shown below

MSChart1.Plot.SeriesCollection(1).DataPoints(-1) _
.Brush.FillColor.Set 0, 255, 255

---

At this point it appears that eric74 has chosen to temporarily deploy his application using a Reg-Free COM manifest that side-by-sides the OCX in question and then copying in an older version that isn't broken next to his EXE. The manifest in question looks dicey to me being quite incomplete, and on startup his EXE may have just self-reg'ed in the older (working) OCX. At least he has a workaround he's comfortable with though.

It also sounds as if a few people have put in support incidents.

Maybe we'll see a fix (to the fix to the fix?) before too long.


If you run into this (installed the "fix" or the "fix fix") and can't roll it back or reinstall Windows, you might consider MMM to help bypass the problem. Note that you'll have to manually copy in libraries earlier than the 6.1.98.12 versions if your build machine has one of those Security Updates already installed.

Hi Dilettante,

You're right, but adding a manifest file was for me the simplest and the
fastest way to solve the problem for end-users, since the addition
of a file in the exe folder does not require a big deployment procedure,
while modifying the exe needs to send the new exe to the packaging team,
which will then be validated by another team etc ... Also in my
sources the latest version contains developpements that are not supposed
to be deployed yet, so I would have to extract an older stable baseline
of the sources, which is not complicated but require to include afterwards
the branch in the latest developments.
In a few words, it requires more administrative stuff ... ;-)

Best regards,

eric
ps: the prototype of the manisfest file (Thanks Bill McCarthy!) is:

> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
> <assemblyIdentity name="Project1" version="1.0.0.0"
> processorArchitecture="X86" type="win32" />
> <file name="mschrt20.ocx">
> <comClass clsid="{3A2B370C-BA0A-11D1-B137-0000F8753F5D}"
> tlbid="{65E121D4-0C60-11D2-A9FC-0000F8754DA1}"
> progid="MSChart20Lib.MSChart.2"
> description="Microsoft Chart Control 6.0 (OLEDB)" />
> </file>
> </assembly>

Great! Glad you can get past this frustrating experience until the situation is corrected.

I generated a manifest myself to check and the COM type information for MSChart20 in Bill's is complete so I have no worries about it now.

How can you do that without XML coded lines?

An application manifest is just an external file or embedded resource containing an XML document. The sample text shown above is a simple manifest. It's XML.

May I ask ? What does the WinShock control do ?

>What does the WinShock control do?

Please start a new thread if you want to know that.

Quote:

---

Originally Posted by iliekater

May I ask ? What does the WinShock control do ?

---

I hope you will not be shocked to know that it is Winsock and not WinShock. :)

Winsock is a networking, IP address handling activex control. That is written to be used in Forms, that require such things to happen in them.

Quote:

---

Originally Posted by dee-u

I hope you will not be shocked to know that it is Winsock and not WinShock. :)

---

rofl. http://www.vbforums.com/images/smilies/biggrin.gif

On topic: I've never have any issue with my normal SP6, so I won't be updating to this patch for a little while longer. Plus, now I'm learning .NET> :D

Is the same factor of upgrading in VB.NET 2005? I was working with VB.NET, but couldn't take the whole thing. So I then went back to VB6 Pro, for the sake of it all.

Quote:

---

Originally Posted by ThEiMp

Is the same factor of upgrading in VB.NET 2005? I was working with VB.NET, but couldn't take the whole thing. So I then went back to VB6 Pro, for the sake of it all.

---

You should not use winsock in .Net anymore, there are the socket classes that replaces the winsock.

Rumor from a VB MVP:

Quote:

---

I wouldn't hold your breath, but the response I got was my request is in the channels and they are aware of other issues and a fix is on the way. I don't know much more than that yet though.

---

I think it's proper to bump this threed and add the information that KB957924 has been updated since the above post

Quote:

---

Article ID: 957924 - Last Review: May 20, 2009 - Revision: 3.3

---

and that a new Visual Basic 6.0 Service Pack 6 Cumulative Update

Quote:

---

File Name: VB60SP6-KB957924-v2-x86-ENU.msi
Version: 6.0
Knowledge Base (KB) Articles: KB957924
Date Published: 5/4/2009
Language: English
Download Size: 9.8 MB

---

is available for download.

I would also like to add that I personally have downloaded and installed this update on Win7 64-bits without any issues noted so far (about a week).

I don't know if it also solve the above issue, so no confirmation on that so far.

So where is the link, that goes with it. Leave it up on the thread...

Quote:

---

Originally Posted by ThEiMp

So where is the link, that goes with it. Leave it up on the thread...

---

Well I only linked to the KB article as it has the link and it might be a good idea to read the article... but edited my post to include the download link as well for those who want to go direct on to it.

Or just use the link in my sig(the last one!(of the first list)).. and get taken directly to the page with all of these downloads on it(and more!).

TIP: None of the "Essential" downloads are essential in any sense of the word. The "Additional Downloads" are the essential downloads for VB6 programmers.

:wave:

The 5/4/2009 "update" corrected a few of the most minor problems, but the serious flaws are still there.

I strongly suggest you do not install this on any production machine and NEVER INSTALL THIS ON A DEVELOPMENT MACHINE.

It is viral in the sense that a developer may package and distribute these flawed components and many users might inadvertantly install them, breaking these component libraries for all non-isolated applications on those machines. Some of the controls I know to be broken in this "security rollup" are the Winsock control (which will return bad values from IP address properties) and the MSChart control (which indexes a number of internal object collections "off by one" producing mangled results and invalid index exceptions).

Once again, note that this patch cannot be uninstalled once you have installed it!

Didn't they beta test the program, in the first place???
I mean that for thirteen years, of my programming professional life. I always sent off my programs to be beta tested. Even, then: They came back with errors, sytax errors, etc...

Quote:

---

Originally Posted by ThEiMp

Didn't they beta test the program, in the first place???

---

Of course they did, but with something of that magnitude (and absolutely enormous existing user code base) it is easy to miss something during testing - or in this case, a few things.

Quote:

---

I mean that for thirteen years, of my programming professional life. I always sent off my programs to be beta tested. Even, then: They came back with errors, sytax errors, etc...

---

Hang on... you have been a professional programmer for more than a couple of days? :eek2:

Why on earth do you still consistently write code like a beginner, such as this from two days ago?

Just the Text1_Change event (6 lines of code) contains 1 obvious mistake that makes it behave incorrectly, obscenely foolish use of On Error Resume Next, blatantly superfluous code, and complete lack of object naming. There is another clear issue too, but it is a bit beyond beginner level.

While Microsoft have apparently made mistakes in this package (I'm not risking checking it myself!) and that is clearly very disappointing, it is extremely naive to pretend that you would have done any part of it better.

Is someone tested update:

1/8/2016
Microsoft Visual Basic 6.0 Service Pack 6 Security Rollup Update
https://www.microsoft.com/en-us/down....aspx?id=50722
VB60SP6-KB3096896-x86-ENU.msi - 9.9 MB
?

It replace mscomctl by version 5-Nov-2015 (list of files).

Is it stable, no new bugs?

EDIT.
I just read a comment of dilettante in thread:

Quote:

---

This set of patches cannot be uninstalled. It contains lots of bugs including quite a few "off by one" coding errors that cause some of the controls patched to become unusable. In some cases internal collections are broken (numeric index vaues are off by 1), in others data gets truncated (Winsock control can return truncated-by-one-char values, e.g. LocalIP).

---

Is some of these bugs (committed in 2012 KB2708437) belongs to mscomctl also?

A programmer I used to collaborate with had accumulated a suite of test programs.

These used several of the controls with known issues and tested instances of them to see if different "discovered" problems were present or fixed in versions of the ill-fated "Security Rollup Fix" releases and re-releases. He tested using a VM for each round of testing because of the problems with being unable to uninstall a Rollup release.

After a while he had switched to extracting the OCXs from each Rollup package, and then used SxS Reg-Free COM manifests with his test programs. This meant he no longer had to install the Rollup attempt packages to test the OCXs inside them. It also meant he didn't need to keep creating fresh VMs because he was never installing Rollup packages.

The problem is, until he knew a bug existed he couldn't devise a test for it. So we never really knew all of the bugs, and worse yet some re-releases of these OCXs fixed a bug and later ones brought it back or added new bugs.


Sadly for us, he never created a table of the known and suspected bugs and their state in different Rollup re-release packages (known only by MSKB numbers, package dates, and the compiled OCX timestamps since Microsoft doesn't give them reliable version numbers we can look for). This programmer has also moved on from Windows programming and only does Android and iOS programming now.

Maybe somebody else has been tracking these and testing them?


At the download page for this re-release of the Rollup:

Quote:

---

This package updates the Microsoft Windows Common Controls, mscomctl.ocx and comctl32.ocx, found in Microsoft Visual Basic 6.0 Service Pack 6. This package will not install these Common Controls if the Visual Basic 6.0 IDE is not installed. This package cannot be uninstalled. Please refer to the security bulletin for additional details.

The Visual Basic 6.0 IDE is no longer supported as of April 8, 2008, however, the Visual Basic team is committed to “It Just Works” compatibility for Visual Basic 6.0 applications

---

These Rollup packages suggest it is really more like "It Works If You're Lucky, Until We Break It Through Ineptitude."

like they did recently with the updated USB portion in windows 10.