WMI Automation Interfaces May Cause Unpredictable Program Shutdowns and Data Loss (292766)

MORE INFORMATION

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:

function Sink::OnObjectReady(obj, ...) {
  sz = obj.Name;
  AddLineToOutput(sz);
}
				

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.