Article ID: 292766 - View products that this article applies to.
This article was previously published under Q292766
This article has been archived. It is offered "as is" and will no longer be updated.
When you run programs that use the asynchronous Windows Management Instrumentation (WMI) automation interfaces, the programs may sporadically and unpredictably stop responding or shut down, possibly causing data loss.
To resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/260910/EN-US/ )How to Obtain the Latest Windows 2000 Service Pack
Microsoft has confirmed that this is a problem in Microsoft Windows 2000.
This problem was first corrected in Windows 2000 Service Pack 2.
Any program that uses asynchronous WMI automation interfaces may be subject to unpredictable behavior due to various timing issues. This behavior may not be identified during development of a program because nested events rarely occur. Though the behavior is not seen on most systems, CPU speed, network speed, system load, and external variables can provoke it and lead to unexpected program termination or to data corruption.
As an example, a JScript garbage collection can cause events to fire, producing an unrecoverable crash in JScript and causing all further script code to stop executing. A later version of JScript (later than Windows 2000) suppresses the sudden stops and shutdowns, but WMI automation still fires events at inappropriate times. In particular, an event can be fired at random times while another event is being processed, easily leading to data corruption in the event handlers.
For example, consider the following JScript:
The intent of the function is to add a string to an output display as objects are returned asynchronously through the OnObjectReady event. Through an effect of JScript garbage collection, the WMI automation interfaces may fire a nested event between the first and second lines of the function. The result is that the nested function overwrites the contents of the variable sz in the middle of the un-nested function. This causes the output to display the nested event twice, and the information about the un-nested event is lost.
The symptoms of the bug are unpredictable because they depend on the timing of garbage collection and on the speed at which asynchronous operations complete. In real-world programs, this bug is the source of problems that show up infrequently, only once in 40 hours of use or in many thousands of repeated successful operations.