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.