The last day has turned out to be one of those days that you spend a lot of time debugging an issue that simply has you tearing your hair out. Now, I doubt that many people will stumble upon this, as they will have applied the solution in the first instance, but I will describe the scenario anyway, as something similar may arise in the future.
I was modifying a Suspend Queue Cleaner application that I wrote that simply cleaned out the Suspend Queue of Suspended Not Resumable messages. The plan was to modify this tool to be a command line utility, accepting parameters and providing a more customised and comprehensive solution that could be called within a scheduled task. It would also be used to provide additional functionality with respect to descriptive alerting so that the operations staff at the client could understand and act upon various error conditions.
I had not looked at this .NET winform utility for some while, but knew it was working under the conditions I wanted to base my new utility on the last time it had gone through the testing cycle. So, off I went stripping out the code I wanted into my new tool.
After creating a basic framework for what was to be the message termination functionality I decided to test that this worked as expected. However, when it came to terminating a Suspended Not Resumable message that I had generated by sending some invalid XML to a test scenario, I was receiving an error “Operation is not supported” with an error code of -1061149508.
Now there are two methods that can be utilised to achieve this: the Terminate method on the MSBTS_ServiceInstance class and the TerminateServiceInstancesByID on the MSBTS_HostQueue class. I happened to be using the former in this case for what I required. Now what was perplexing about this was the fact that I knew this particular line of code had worked previously. I was simply iterating through a collection of some ServiceInstances and invoking this method similar to the code below:
foreach(ManagementObject manObj in searchObj.Get()) {
manObj.InvokeMethod("Terminate", new object[]{});
}
So, I set about testing it with the various ways to achieve Suspended Not Resumable messages believing it may be that the utility had only managed to remove a certain type of Suspened Not Reusmable message previously. No luck there.
I then attempted to alter the way in which I was retrieving the ServiceInstance by accessing it directly and passing in the GUID and when that failed tried using the second method of terminating.
At this point I went through all the properties that were being exposed for the ServiceInstance class and noticed that the ServiceClassId property was empty for those instances that were Suspended Not Resumable, but was populated for Suspended Resumable.
Aha, now we were getting somewhere. I assumed the method was failing as it required this property to perform the terminate functionality. But why would this property not be populated? At the same time I noticed that a test scenario I had used to generated a Suspended Not Resumable message had actually been cleaned using the method that was failing. The only difference I could find was that this scenario was utilising the File Adapter whereas the failing scenario was using HTTP.
Naturally I then spent some time examining the installation of the HTTP adapter, but could not discover anything that would lead me to believe anything was causing this issue. In typical hold your hands up and murmur some expletives style I decided to reinstall BizTalk 2004 stage-by-stage to determine if any stage in the process unearthed the answer.
Low and behold that after reinstalling BizTalk (and testing against the vanilla version to find it did not fix the problem) and then applying the Rollup Package everything worked as expected. I had assumed the Rollup Package had been installed on this machine as part of the standard build process at my client, which was obviously the wrong assumption to make!
The lesson learnt from this extremely unproductive day? Double check that you have all the latest patches applied to your development machines prior to undertaking extensive debugging investigation!