Dr Watson can cause 4.62x DP4 to hang - A4000028 - 27 Jan 2005

If one of the DP4 interface programs, (all DP4 files with .w32 extension), generates an exception then applications should receive a FAIL 9 error, and it should be possible to shut the DP4 service down relatively cleanly. On some versions of Windows, if Dr Watson (DRWTSN32.EXE) is installed as the application debugger, then instead of terminating, DP4 hangs completely: if DP4 is running as a service the computer has to be rebooted before DP4 can run again; if DP4 is running as an application it is necessary to log off and log back on. No DP4 error messages are displayed.

Exactly which versions of Windows may be affected by this problem is is not yet known: so far it has only been seen on Windows 2000 server, but the problem may well arise on other versions. (It seems not to arise on Windows XP - if Dr Watson fails to attach the faulting program terminates). Security settings are likely to strongly influence whether this problem can arise or not. Windows 9x/Me versions are definitely not affected.

The cause of the problem is an interaction between a change made to DP4 for 4.620 and a bug in Dr Watson: from 4.620 the DP4 interface programs attempt to secure their process space from other programs. This is a security measure: malicious programs may try to create threads in service programs as a means of acquiring enhanced privileges and performing an exploit. On some machines DP4 is extremely successful in locking itself down, and as a result Dr Watson may be unable to attach to DP4 interface programs to produce its log file. When this happens, instead of allowing the DP4 program to terminate, the program is kept in limbo for ever, and the entire DP4 system grinds to a halt.

In order to solve it is necessary to change DP4, as Microsoft are unlikely to fix Dr Watson. If you need to know whether or not your Windows configuration is affected we can send a program that can be run as part of the DP4 service that will deliberately crash. If DP4 fails to terminate then your Windows configuration is affected. Added 27 Jan 2005 A fix for this problem is available in release 4.621a and 4.622. In those releases dp4srvr.w32 handles its own exceptions.

Work Around Solutions

There are several possible work-arounds for this problem:

• Disable Dr Watson

  1. Log on as a user with administrator rights and start REGEDIT

  2. Locate the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug registry key. Either delete the entire key, or delete the Debugger string. (The string probably reads something like drwtsn32 -p %ld -e %ld -g)

  WIth this solution, when an exception occurs, programs just display an error message detailing the location of the error, but no error log is created. However, if you have a reproducible problem witha DP4 interface program this will at least allow you to discover something about the error.

• Prevent Dr Watson Running Automatically

  (This solution is not suitable for end-users unless they are expected to be relatively experienced Windows users)

  1. Start REGEDIT and locate the same registry key as described above. Change the Auto value from 1 to 0.
  2. Inform your users that if a DP4 interface program generates an exception they should press OK to Terminate, and NOT press Cancel to debug it.

  Alternatively, start DRWTSN32 from the run prompt and make sure the "Visual Notification" check box is checked, and then press OK to save the configuration. In this case Dr Watson will still leave DP4 in limbo, but at least a visible error message is generated that will alert users to the fact that there is a problem.

• Grant Debug Program rights to the users who will be running DP4.

  This solution is not suitable where security is a concern: malicious programs can use debug privilege to gain control over a computer.

  The Debug Programs right is accessed from the User Rights option of User Manager on Windows NT, and is in the User Rights Assignment folder in Administrative Tools, Local Security Policy on Windows 2000/XP work stations, or Group Security Policy on Domain Controllers.

• Alter DP4 configuration to run DP4 in secure mode

  This solution is only effective if you have a syslibnt.dll dated on or after 26 April 2003.

  Instructions for running DP4 in secure mode can be found in Security in the Guide to DP4 Configuration. In fact the following changes to DP4.INI should be sufficient:

  • In the [win32] section add a dummy user entry, e.g.: user=fred

  • Specify -secure=0 on the command line to the following DP4 components:

    • dp4srvr.w32
    • tcpmgr.w32
    • tcpw.w32 (this last is only necessary for 4.620, and not 4.621)

    Alternatively, add secure=0 to the [tcpmgr], [tcpw],and [dp4srvr] sections of dp4.ini (you will probably need to create these sections)