This article lists the Microsoft COM+ bugs that are fixed in
the Microsoft Windows Server 2003 COM+ 1.5 Rollup Package 1. The Windows Server
2003 COM+ 1.5 Rollup Package is cumulative. Each package contains all the fixes
that are released in the previous Windows Server 2003 COM+ 1.5 Rollup Packages.
Marshaling the CLIPFORMAT Data Type Does Not Work Across Terminal Sessions
In a Component Object Model (COM) client server
environment, marshaling of the CLIPFORMAT data type does not work while marshaling for processes runs in
terminal server sessions on a Microsoft Windows Server 2003 Terminal Server. If
the callback function passes the CLIPFORMAT data type, the clients do not receive callbacks. This behavior
occurs when an instance of the client starts and then runs before it starts any
terminal server sessions, and while it runs clients from the terminal
server.
Access Violation Error While You Specify a Constructor String in COM+
When you try to specify a constructor string in COM+
application activation settings, you may receive the following error message:
Access Violation
Eventlogs are not logged when the caller is not an administrator
Rpcss.exe (A system component) impersonates the
activating client it calls the event log Application Programming Interfaces
(API). If the activating client does not have administrative rights, the
eventlog cannot open and does not log the COM activation eventlog
messages.
In this fix, Rpcss.exe unimpersonates around the calls to
the eventlog APIs. Therefore, these calls are made as SYSTEM.
Mtxoci.dll Blocks All Transactions in Asynchronous Aborts
Mtxoci.dll is a dynamic-link library (DLL) that is used
internally by the Microsoft ODBC Driver for Oracle and by the Microsoft OLE DB
provider for Oracle in conjunction with Microsoft Distributed Transaction
Coordinator (MSDTC) to provide transactional support to Oracle databases. When
Mtxoci.dll receives an asynchronous abort call, it handles the call
synchronously. Because DTC shares buffers for all calls that are made on a
connection by using a boxcar
mechanism, all other transactions to the same database may be
blocked.
In this fix, a queue is added for incoming calls to
Mtxoci.dll. All the asynchronous abort calls are queued and are returned
without requiring Oracle to handle the asynchronous aborts.
Activations for Partitioned Components Fails on a Microsoft Windows NT 4 Client
When a Microsoft Windows NT 4 client tries to activate a
partitioned COM+ component, COM+ does not activate the partitioned component.
Before COM+ activates any components, it verifies the identity of the user who
tries to activate the component and verifies that the user has rights to access
the partition set where the component resides. If no client context exists,
COM+ does not activate the partitioned component. Because Windows NT 4 clients
have no context, this may cause the partition activation to fail.
In
this fix, COM+ enables partitioned components to activate without a client
context.
The IPlaybackControl::FinalClientRetry Method Is Not Called
The IPlaybackControl::FinalClientRetry method informs the client-side exception-handling component that
all Message Queuing tries to deliver the message to the server were rejected.
The message is on to the client-side Xact dead letter queue. However, IPlaybackControl::FinalClientRetry is not called because the client-side dead letter queue listener
application has a bug in Microsoft Windows 2000. This bug causes the dead
letter queue listener application to stop functioning (this throws an Access
Violation exception) as soon as the dead letter queue listener application
tries to process a message in the dead letter queue. Therefore, no dead letter
queue Queued Components (QC) messages are processed at the client-side.
In this fix, each successive message in the dead letter queue is
peeked and then verified that it is a QC message. If it is not a QC message,
the message is skipped. If it is a QC message, the message is processed by
using the user-specified class. A peek operation returns a small subset of
properties and the verification procedure tries to access a property that does
not return and the procedure stops functioning.
MSDTC Deadlocks While It Performs a Read/Write Operation in a Multithreaded Application
MSDTC uses a read or write semaphore that is not fully
re-entrant. MSDTC deadlocks if thread 1 owns a read lock, thread 2 tries to get
a write lock, and thread 1 tries to reacquire the read lock.
In this
fix, a read or write semaphore is modified to handle the deadlock
situation.
MSDTC Shuts Down Automatically When the Log File Is Full
The MSDTC uses a log file to monitor and to store
statistics for distributed transactions. However, when the log file is full,
MSDTC may shut down automatically.
The COM+ Proxy DLL Does Not Overwrite in the COMPLUS\{GUID} Folder While Installing an Application Proxy With the New Version
COM+ supports installing application proxies over
previous versions of the same application. The files for the new application
proxies go in the exact same location as the previous files. When the new proxy
contains new binaries with updated file versions, the proxy sometimes installs
correctly, but the old files still exist. If the new file already exists (by
name) on the disk, Microsoft Windows Installer performs a file version
comparison of the old on-disk file and the new file version that is stored in
the Windows Installer file metadata. Because COM+ does not set the file version
in the metadata (COM+ writes the hard-coded file version as "1.1.1.1"), Windows
Installer will not update the file on the disk.
In this fix, when
files are added to the Windows Installer file, the MsiGetFileVersion function is called to get the version of the file and the locale
of the file. This information is put in the Windows Installer file. If the
MsiGetFileVersion API fails for any reason, COM+ will return to the original
behavior (using a hard-coded version string of "1.1.1.1").
Microsoft Windows Server 2003 Displays the Incorrect Display Names for Groups in MUI Systems
The COM+ catalog always stores user names as strings
instead of security identifiers (SIDs). This does not always work for built-in
user accounts. In a Multi User Interface (MUI) system, this may create
confusion to the user. For example, in a Multi User Interface (MUI) system, a
German language user connects and then adds "Jeder" (Everyone in German) to a
role. Later, an English language user connects, and then sees "Jeder" in his
User Interface (UI) instead of "Everyone". This is not a security threat in
itself (it is correct to add the same user multiple times to an Access Control
List (ACL)), but it can be confusing to users because they may believe a
potentially unauthorized person may have their role. You may experience this
bug if you apply the fix that is detailed in the following Knowledge Base
article:
281454
(http://support.microsoft.com/kb/281454/
)
You Cannot Apply Local Security Settings with MUI
In this fix, when a new user is added to a role, the
Windows Server 2003 system verifies if the user is a built-in identity (for
example, Everyone or Administrator). If it is, a textual SID is returned for
this user and the SID is stored in the RoleMemberName column in the catalog
(for other users, the system still stores the regular name. For example, the
system will store
domain\username). The
Administrative Software Development Kit (SDK) sends the RoleMemberName column
to the programs that are using the SDK. In the SDK, an edit rule is added for
Role Member names. This rule tries to convert the string that is returned from
the catalog server to a SID by using the ConvertStringSidToSid function. If this function fails, the rule assumes that the
string is not a textual SID and then the rule returns the string untouched to
the SDK client. If the function succeeds, the LookupAccountSid function is called and returns an appropriate localized name for
the current process. Therefore, English language administrators can now add
"Everyone" to a role and then a German language admin will see "Jeder".
Warning When someone from a client computer that does not have this fix
performs remote administration of a server that does, the server returns a raw
textual SID to the client computer and the client computer displays that SID
without any changes. After the fix is applied on the client computer, correct
names also display on the client computer.
The COM+ System Tracker Does Not Reset Statistics for an Idle Component
In Windows Server 2003, the COM+ System Tracker ignores
the Idle status of components if other components in an application are not
idle. When a component fails, the last-called method and the Idle state are
shown as failed until the whole application is idle. This may confuse the
AppCenter personnel who rely on this data from the tracker to decide an
additional course of action.
In this fix, an extra Idle status check
is added for every class so that if a class is Idle for four consecutive sweeps
(each sweep occurs after one second) of the tracker thread it is marked as
dirty so that the tracker sets the idle status of the class to the system
application. Once this is done, however, the status of this component is not
updated until the component returns back from its idle state.
SQL Service May Fail Because of a Nonexistent MSDTC Service
On clusters, the recommended configuration for MSDTC is
to run as a cluster resource. In such configurations, if a customer has
installed a non-clustered or local instance of SQL Server on one of the
clusters (by default, such a SQL service will start automatically at system
startup), the local SQL Service may try to start before the MSDTC cluster
resource has started. In this case, the local SQL Service loads the
Msdtcprx.dll library, starts a local instance of MSDTC, and obtains a proxy
core object for this local instance of MSDTC. When the clustered MSDTC service
comes online, the local MSDTC service quits and the clustered MSDTC service
starts up. The proxy core object in the SQL service points to a non-existent
MSDTC service, and the SQL service may fail with the following error
message:
MSDTC on server
'servername' is unavailable.
In
this fix, if the cluster state is configured but is not running, and if the
local DTC service is not running, the request from SQL service is rejected. The
proxy core object does not have to be initialized until the cluster service
comes up and the DTC resource exists. If the local DTC service is running, this
must be in special case during setup. In this case, initialization may
continue.
The AuthenticationCapability Property on the Application Object Rejects Valid EOAC_ Value
COM+ has a bug in the admininstrative SDK that prevents
application administrators from configuring their COM+ applications to run with
the EOAC_DISABLE_AAA value, the EOAC_NO_CUSTOM_MARSHAL, or both. This is an
existing bug in its own right.
In this fix, the values
EOAC_DISABLE_AAA and EOAC_NO_CUSTOM_MARSHAL are added to the range of permitted
values that are accepted for the AuthenticationCapabilities property on the COM+ SDK application object. For server
applications, this value is passed through unchanged to the CoInitializeSecurity function from Dllhost.exe.
Memory Leak Occurs When Different Threads Use the Global Interface Table (GIT) from Different Threads
The object exporter identifier (OXID) cleanup worker
thread is not created until the thread unmarshals an object. However, if
somebody initializes an apartment, unmarshals the free-threaded marshaler (FTM)
object (or another custom marshaled object), and uninitializes the apartment,
the worker thread is not created. A memory leak in the process may occur if
this procedure are repeated. This is because of the OXID entries in the cleanup
list fill up the list.
In this fix, the worker thread starts in the
apartment creation path, in addition to the unmarshal path. The worker thread
is created if necessary.
A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.
If the hotfix is available for download, there is a "Hotfix download available" section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.
Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:
Note The "Hotfix download available" form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.
Prerequisites
Microsoft Windows Server 2003
Restart Requirement
You must restart your computer after you apply this hotfix.
Hotfix Replacement Information
This hotfix does not replace any other hotfixes.
File Information
The English version of this hotfix has the file
attributes (or later) that are listed in the following table. The dates and
times for these files are listed in coordinated universal time (UTC). When you
view the file information, it is converted to local time. To find the
difference between UTC and local time, use the Time Zone tab
in the Date and Time tool in Control Panel.
Back to the top
