- 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 You Cannot Apply Local Security Settings with MUIIn 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.
Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.