BizTalk Document Tracking crashes Internet Explorer after installing KB973525

You need to remove KB973525.

The Flat File Serilaziser (CISSerializer) does not support XML comment!

If you put some comments within the XML result of your mappings (by using ) you might get a dodgy error message as follow, and your message will probably be stuck in the Work Queue:

Event Type: Error
Event Source: COM+
Event Category: SVC
Event ID: 4194
Date:  16/02/2009
Time:  15:09:43
User:  N/A
Computer: MyComputer
Description:
The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below. 
Component Prog ID: 
Server Application ID: {6ECD95AC-3C06-4A9B-9D43-4565C1BD3319}
Server Application Name: BizTalk Server Internal Utilities
Exception: C0000005
Address: 0x72E5DC94
Call Stack: 
msxml3!DllGetClassObject + 0x55FB
msxml3!DllGetClassObject + 0x589F
msxml3!DllCanUnloadNow + 0x1BA80
msxml3 + 0x7B9D1
CISSerializer!DllUnregisterServer + 0x110E3
CISSerializer!DllUnregisterServer + 0x1127C
CISSerializer!DllUnregisterServer + 0x1127C
CISSerializer!DllUnregisterServer + 0x129CF
CISSerializer!DllUnregisterServer + 0x97DC
CISENGINE!CSingleList::CSingleList(void) + 0x8624
CISENGINE!CSingleList::CSingleList(void) + 0x571F
CISENGINE!CSingleList::CSingleList(void) + 0x403F
CISENGINE!GetNewStateEngine(struct IInterchangeStateEngine * *) + 0x1354
CISENGINE!GetNewStateEngine(struct IInterchangeStateEngine * *) + 0x10A8
CISENGINE!GetNewStateEngine(struct IInterchangeStateEngine * *) + 0xBE0
CISENGINE!GetNewStateEngine(struct IInterchangeStateEngine * *) + 0x499
CISENGINE!GetNewStateEngine(struct IInterchangeStateEngine * *) + 0x6EE
CISENGINE!LKRhash::CLKRHashTable::End(void) + 0x5CAA
TxfAux + 0x35C61
ole32!CoCreateFreeThreadedMarshaler + 0x2EA1
ole32!CoCreateFreeThreadedMarshaler + 0x3160
ole32!CoCreateFreeThreadedMarshaler + 0x3517
TxfAux!CoGetInterceptorForOle32 + 0x2FD7
MSCIS!SchedulerRunning(void) + 0x105E
KERNEL32!lstrcmpiW + 0xB7

How to validate Unicode non-XML document instances containing the byte order mark (byte order marker or BOM) 0xFFFE with BizTalk 2000 or 2002

The documentation for both BizTalk 2000 (1) and BizTalk 2002 (2) clearly states that it is not possible: << Non-XML document instances saved in Unicode will not validate correctly unless you remove the byte order marker at the beginning of the file. >>

(1) http://msdn.microsoft.com/en-us/library/ms957204.aspx
(2) http://msdn.microsoft.com/en-us/library/ms865274.aspx

I was really pissed off by this [beeping] limitation, and a few spots already appeared on my face thinking about the custom piece of code a Microsoft consultant would propose to me in order to fix this [beeping] "bug". Googling on this limitation makes my spots even bigger!

Then, I decided to make some research myself to check if it is not possible to find a decent workaround, and... I am a GENIUS - I mean I find a decent workaround. By the way, as mentioned to my colleague, I will probably not be recognised as a genius as no one is using BizTalk 2000/2002 anymore ;-) Anyway, I decided to write this post, here is my solution!

When you parse a Unicode non-XML document instance containing the byte order mark 0xFFFE, the problem is that you get the Unicode character 0xFEFF - do not ask me why you do not get 0xFFFE, ask the Microsoft guys ;-) - as the first character of the value of your first field. And, there is an easy technique to remove it... make it the "Pad Character", I am a genius ;-) Here are more details:

1. In BizTalk Editor, select your 1st field of your specification
2. Click on the "Parse" tab
3. Select "Right" for the "Justification" property
4. Type 0xFEFF for the "Pad Character" property - When you click in the "Value" cell of the "Pad Character" property, the text "TAB (0x9 )" automatically appears, and then you have to carefully replace the "9" by "feff" and press "Enter"
5. Save your specification

Your BizTalk Document Specification should now parse Unicode non-XML document instances containing the byte order mark 0xFFEE without any problem... you’re welcome ;-) By the way, your BizTalk Document Specification should continue to parse Unicode non-XML document instances without the byte order mark too!