This is referring to MS03-043 on a Windows 2000 system scanning with MBSA 1.2 (the mbsa version is important, as different versions of MBSA use entirely different XML files) The entry in the XML file used by MBSA 1.2 references two files for this patch. The XML file does not list any reg keys for this entry, therefore reg keys are not being used. The MBSA engine is reading the files from disk. That you are not seeing it as missing, means it sees the expected file version on disk. Simultaneously, third party tools are telling you that the vulnerability still exists. Not knowing exactly how these third party tools operate, we can still reach a conclusion where all tools are operating 'by design'. The expected new files are on the target system - they have been written to disk and are no longer sitting in pendingfilerename queues. However, the system executed these files and placed them in memory when the services were started, presumably before the patch was applied. So the copy of the file in memory (and currently in execution) is the old vulnerable copy, while the copy of the file on disk is the new copy, not yet placed into execution. Restarting these services, or restarting the box will make the service reload the files from disk, thus placing the new files into execution on the stack against which the third party vulnerability scanning products are testing. No reg keys involved - just a difference of file on disk vs. file in memory\execution. --eric
