KB5094123 update causes RDS.DataSpace Optional parameter to reset to default value after COM+ function call

Question

KB5094123 update causes RDS.DataSpace Optional parameter to reset to default value after COM+ function call

홍준호 0

After installing Windows Server 2019 KB5094123 (June 2026 Patch Tuesday), we are experiencing an issue where Optional parameters passed to a COM+ DLL via RDS.DataSpace are being reset to their default values after an internal sub-function call returns.

Environment:

OS: Windows Server 2019 (Build 17763.8880)
KB: KB5094123 (installed June 9, 2026)
Stack: VB6 COM+ DLL + RDS.DataSpace + ADO (SQLOLEDB)

Symptom:

A VB6 function declared with an Optional parameter:

vb

Public Function fProcess(Optional IN_DATE As String = "") As Boolean

When called remotely through RDS.DataSpace, the value of IN_DATE passed by the caller (e.g. "20260531") is correctly received inside the function, but after returning from an internal sub-function call, IN_DATE reverts to its default value "".

This behavior does not occur before KB5094123 is installed.

Workaround:

Uninstalling KB5094123 resolves the issue:

wusa /uninstall /kb:5094123 /quiet /norestart

Question:

Is this a known behavioral change introduced by KB5094123 regarding RDS.DataSpace and Optional parameter handling in COM+ calls? Is there a planned fix or official workaround?

Viorel 127.3K Reputation points

2026-06-23T05:23:01.5033333+00:00

Does this happen even if the internal function does nothing (is temporarily empty)?
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
홍준호 0 Reputation points

2026-06-23T05:46:05.8866667+00:00
Thank you for your question. After further analysis, we believe the root cause may be related to parameter aliasing rather than the internal function itself.

We discovered that the same variable was being passed twice in the RDS.DataSpace COM+ call — once as a regular parameter and once as an Optional parameter.

Simplified example:

Dim myDate As String

myDate = "20260531"

' Same variable passed to two different parameter positions

obj.fProcess(myDate, "A", "B", myDate)

' ↑ regular param ↑ Optional param (same variable)

Function declaration:

Public Function fProcess(ByVal p1 As String,

ByVal p2 As String, ByVal p3 As String, Optional IN_DATE As String = "") As String

Before KB5094123, RDS.DataSpace appeared to create separate copies of each parameter during marshaling, which prevented aliasing side effects.

After KB5094123, it appears RDS no longer creates these copies, causing both parameter positions to share the same memory reference. When the Optional parameter gets reset to its default value ("") during marshaling or execution, the original variable is also affected.

Workaround we applied:

Dim strDate As String

strDate = myDate ' copy to separate variable before call

obj.fProcess(strDate, "A", "B", myDate)

This resolved the issue by breaking the shared reference.

Our question: Did KB5094123 change the parameter marshaling behavior in RDS.DataSpace, specifically regarding whether independent copies are made per parameter position? This would explain why aliasing — passing the same variable to multiple parameter slots — now causes unexpected behavior.

2 answers

Your answer

Viorel 127.3K Reputation points

2026-06-23T05:23:01.5033333+00:00

Does this happen even if the internal function does nothing (is temporarily empty)?
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
홍준호 0 Reputation points

2026-06-23T05:46:05.8866667+00:00

Thank you for your question. After further analysis, we believe the root cause may be related to parameter aliasing rather than the internal function itself.

We discovered that the same variable was being passed twice in the RDS.DataSpace COM+ call — once as a regular parameter and once as an Optional parameter.

Simplified example:

Dim myDate As String

myDate = "20260531"

' Same variable passed to two different parameter positions

obj.fProcess(myDate, "A", "B", myDate)

' ↑ regular param ↑ Optional param (same variable)

Function declaration:

Public Function fProcess(ByVal p1 As String,

ByVal p2 As String, ByVal p3 As String, Optional IN_DATE As String = "") As String

Before KB5094123, RDS.DataSpace appeared to create separate copies of each parameter during marshaling, which prevented aliasing side effects.

After KB5094123, it appears RDS no longer creates these copies, causing both parameter positions to share the same memory reference. When the Optional parameter gets reset to its default value ("") during marshaling or execution, the original variable is also affected.

Workaround we applied:

Dim strDate As String

strDate = myDate ' copy to separate variable before call

obj.fProcess(strDate, "A", "B", myDate)

This resolved the issue by breaking the shared reference.

Our question: Did KB5094123 change the parameter marshaling behavior in RDS.DataSpace, specifically regarding whether independent copies are made per parameter position? This would explain why aliasing — passing the same variable to multiple parameter slots — now causes unexpected behavior.

Answer 1

Thank you for your question. After further analysis, we believe the root cause may be related to parameter aliasing rather than the internal function itself.

We discovered that the same variable was being passed twice in the RDS.DataSpace COM+ call — once as a regular parameter and once as an Optional parameter.

Simplified example:

Dim myDate As String

myDate = "20260531"

' Same variable passed to two different parameter positions

obj.fProcess(myDate, "A", "B", myDate)

' ↑ regular param ↑ Optional param (same variable)

Function declaration:

Public Function fProcess(ByVal p1 As String,

                       ByVal p2 As String,

                       ByVal p3 As String,

                       Optional IN_DATE As String = "") As String

Before KB5094123, RDS.DataSpace appeared to create separate copies of each parameter during marshaling, which prevented aliasing side effects.

After KB5094123, it appears RDS no longer creates these copies, causing both parameter positions to share the same memory reference. When the Optional parameter gets reset to its default value ("") during marshaling or execution, the original variable is also affected.

Workaround we applied:

Dim strDate As String

strDate = myDate ' copy to separate variable before call

obj.fProcess(strDate, "A", "B", myDate)

This resolved the issue by breaking the shared reference.

Our question: Did KB5094123 change the parameter marshaling behavior in RDS.DataSpace, specifically regarding whether independent copies are made per parameter position? This would explain why aliasing — passing the same variable to multiple parameter slots — now causes unexpected behavior.

Answer 2

Thanks for sharing your detailed analysis.

From your findings, the issue happens because the same variable is passed to two different parameters. After the update, both parameters appear to share the same reference. So when the Optional parameter resets to its default value, it also affects the original variable. Using a separate variable, as you have done, is the correct way to avoid this issue.

Since this behavior is not clearly documented, we recommend reporting it to the product team through the https://developercommunity.microsoft.com/

so, they can review and clarify this behavior.

If you found this information useful, kindly mark this as "Accept Answer" so that others facing similar issues can easily find the solution. We are closing this thread for now. If you encounter any further issues, please feel free to raise a new thread.