Regression in OLE Automation after KB5094122 on Windows Server 2016

Title: Regression in OLE Automation after KB5094122 on Windows Server 2016

This is a Windows Server runtime regression affecting OLE Automation (oleaut32.dll).

Environment

• OS: Windows Server 2016

Update Installed: KB5094122 (June 2026 Cumulative Update)

COM Component: VB6 COM DLL hosted in COM+ Server Application (dllhost.exe)

Client: Classic ASP and VBScript (cscript/wscript)

Architecture: Issue reproduced in both ASP and standalone VBScript environments

Problem Summary

After installing KB5094122, COM Automation calls exhibit abnormal behavior when the same variable is passed multiple times as ByVal String parameters to a COM object.

The issue did not occur before KB5094122 installation.

The behavior is reproducible in both:

Classic ASP -> COM+

VBScript -> COM+

COM+ -> COM+

The issue appears independent of IIS and can be reproduced from a standalone VBScript script.

Observed Behavior

Example VBScript:

Set obj = CreateObject("testOleaut.TEST001")

a = "100"
b = "200"

MsgBox obj.Echo1(a, a, b, b)

MsgBox "VarType(a)=" & VarType(a)
MsgBox "Len(a)=" & Len(a)

MsgBox "VarType(b)=" & VarType(b)
MsgBox "Len(b)=" & Len(b)

VB6 COM Component:

Public Function Echo1( _
    ByVal A1 As String, _
    ByVal A2 As String, _
    ByVal B1 As String, _
    ByVal B2 As String) As String

    Echo1 = "[" & A1 & "][" & A2 & "][" & B1 & "][" & B2 & "]"

End Function

Expected Result:

[100][100][200][200]

VarType(a)=8
Len(a)=3

VarType(b)=8
Len(b)=3

Actual Result:

[][100][][200]

VarType(a)=0
Len(a)=0

VarType(b)=0
Len(b)=0

The caller variables become VT_EMPTY after the COM call.

This occurs even though all COM parameters are declared as ByVal String.

Additional Findings

The problem only occurs when the same variable instance is passed multiple times.

Failing example:

obj.Echo1(a, a, b, b)

Working example:

obj.Echo1(a & "", a & "", b & "", b & "")

Result:

[100][100][200][200]

The caller variables remain unchanged.

The workaround above forces creation of new BSTR instances and avoids the problem.

Control Test

The same code executed entirely inside VBScript functions (without COM Automation) works correctly.

Example:

Function Echo1(A1, A2, B1, B2)
    Echo1 = "[" & A1 & "][" & A2 & "][" & B1 & "][" & B2 & "]"
End Function

a = "100"
b = "200"

MsgBox Echo1(a, a, b, b)

Result:

[100][100][200][200]

No variable corruption occurs.

Conclusion

The issue appears related to COM Automation / IDispatch parameter marshaling after KB5094122.

Evidence suggests that when identical VARIANT/BSTR instances are passed multiple times within a single Automation call, the original caller-side VARIANTs are unexpectedly converted to VT_EMPTY after the call returns.

Because the issue reproduces from standalone VBScript and COM+ to COM+ calls, it does not appear to be IIS-specific.

Request

Please investigate whether KB5094122 introduced a regression in OLE Automation (oleaut32.dll), VARIANT handling, BSTR lifetime management, or IDispatch parameter marshaling.

We would appreciate confirmation of whether this is a known issue and whether a hotfix or workaround is available.Title: Regression in OLE Automation after KB5094122 on Windows Server 2016

Environment

OS: Windows Server 2016

Update Installed: KB5094122 (June 2026 Cumulative Update)

COM Component: VB6 COM DLL hosted in COM+ Server Application (dllhost.exe)

Client: Classic ASP and VBScript (cscript/wscript)

Architecture: Issue reproduced in both ASP and standalone VBScript environments

Problem Summary

After installing KB5094122, COM Automation calls exhibit abnormal behavior when the same variable is passed multiple times as ByVal String parameters to a COM object.

The issue did not occur before KB5094122 installation.

The behavior is reproducible in both:

Classic ASP -> COM+

VBScript -> COM+

COM+ -> COM+

The issue appears independent of IIS and can be reproduced from a standalone VBScript script.

Observed Behavior

Example VBScript:

Set obj = CreateObject("testOleaut.TEST001")

a = "100"
b = "200"

MsgBox obj.Echo1(a, a, b, b)

MsgBox "VarType(a)=" & VarType(a)
MsgBox "Len(a)=" & Len(a)

MsgBox "VarType(b)=" & VarType(b)
MsgBox "Len(b)=" & Len(b)

VB6 COM Component:

Public Function Echo1( _
    ByVal A1 As String, _
    ByVal A2 As String, _
    ByVal B1 As String, _
    ByVal B2 As String) As String

    Echo1 = "[" & A1 & "][" & A2 & "][" & B1 & "][" & B2 & "]"

End Function

Expected Result:

[100][100][200][200]

VarType(a)=8
Len(a)=3

VarType(b)=8
Len(b)=3

Actual Result:

[][100][][200]

VarType(a)=0
Len(a)=0

VarType(b)=0
Len(b)=0

The caller variables become VT_EMPTY after the COM call.

This occurs even though all COM parameters are declared as ByVal String.

Additional Findings

The problem only occurs when the same variable instance is passed multiple times.

Failing example:

obj.Echo1(a, a, b, b)

Working example:

obj.Echo1(a & "", a & "", b & "", b & "")

Result:

[100][100][200][200]

The caller variables remain unchanged.

The workaround above forces creation of new BSTR instances and avoids the problem.

Control Test

The same code executed entirely inside VBScript functions (without COM Automation) works correctly.

Example:

Function Echo1(A1, A2, B1, B2)
    Echo1 = "[" & A1 & "][" & A2 & "][" & B1 & "][" & B2 & "]"
End Function

a = "100"
b = "200"

MsgBox Echo1(a, a, b, b)

Result:

[100][100][200][200]

No variable corruption occurs.

Conclusion

The issue appears related to COM Automation / IDispatch parameter marshaling after KB5094122.

Evidence suggests that when identical VARIANT/BSTR instances are passed multiple times within a single Automation call, the original caller-side VARIANTs are unexpectedly converted to VT_EMPTY after the call returns.

Because the issue reproduces from standalone VBScript and COM+ to COM+ calls, it does not appear to be IIS-specific.

Request

Please investigate whether KB5094122 introduced a regression in OLE Automation (oleaut32.dll), VARIANT handling, BSTR lifetime management, or IDispatch parameter marshaling.

We would appreciate confirmation of whether this is a known issue and whether a hotfix or workaround is available.