If we could only control that window class...

This is an example of a file run from within a local chm file.
Local chm files are considered as executables.
The following is a research into an interesting bug and NOT a
discussion on a practical security vulnerability. 

[OBJECT
  id=hh
  classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11"
  width=100
  height=100
]
  [PARAM name="Command" value="ShortCut"]
  [PARAM name="Button" value="Bitmap:shortcut"]
  [PARAM name="Item1" value=",cmd,/c"]
  [PARAM name="Item2" value="273,1,1"]
[/OBJECT]

[script]

 // The chm loads, executes a process and the process is closed
 // The the script clicks the shortcut object after the process has already been closed
 // then hh.exe tries to create an error message using a format string (wsprintfA). The error message is:
 // "The program specified for the shortcut was started, but the window class "%s" could not be found."
 // Then there is an attempt to read from the window class that was assigned to the process executed, which was
 // FREEed/destroyed/released when the process was closed. This causes the address that is pulled from the stack to be 3 letters 
 // from the error message itself and another byte " th\x54"

 // an exploitation would require to be able to manipulate the window class
 // a proper fix would be one of the following:
 //  1) Checking if the window class still exists before using it
 //  2) making a copy of the window class upon process creation and using that copy
 //  3) removing the format string message

 hh.Click();
[/script]