16-BIT DOS / WINDOWS APPLICATIONS
Description: In general, 16-bit DOS or Windows application failures are treated the same as any other application failure. The sole exception is the fact that 64-bit Windows includes no 16-bit emulation. Because of this, no 16-bit application will be compatible with 64-bit Windows.
Scoping the Issue: First, determine the exact symptom you are experiencing. Is the application hanging, throwing an error, performing badly or crashing? Each of these will require different troubleshooting steps be carried out.
For application hangs, there are a couple of things that you can do. First, check Task Manager. If the process is unresponsive but is not listed as “Not Responding” in Task Manager, then the application may be functioning normally but is waiting for data – possibly from a network resource. If you are experiencing an issue as a result of a network bottleneck or network resource failure, the symptom will most likely be evident on multiple client systems – where all their applications waiting on that resource, or set of resources become unresponsive at the same time. In some instances, the application may be functioning quite normally, however it is actually waiting for user input, but the user input box has somehow been hidden behind other open windows. If however, the application is listed as “Not Responding” in Task Manager, then it may truly be hung, but keep in mind are some scenarios where applications that are waiting for network resources may also be listed as “Not Responding”.
Application crashes are usually easy to spot. In most instances, the application exits, and an error message from Dr. Watson or Windows Error Reporting will be displayed. In many instances, the error message will indicate an Access Violation of some sort and a user-mode dump of the process will be created.
Data Gathering: In all instances, collecting either MPS Reports with the General, Internet and Networking, Business Networks and Server Components diagnostics, or a Performance-oriented MSDT manifest must be done. Additional data required may include the following:
- In the event of a hang, we may need to capture a dump (or a number of dumps) of the application while it is in its unresponsive state. You can do this by either running ADPLUS.VBS from the Windows Debugging Tools in hang mode. On Windows Vista and later operating systems, you can also create a dump of the process from within Task Manager. To do this, highlight the process, right-click and select the “Create Dump File” option.
- For an application crash, check to see if a crash dump has been created. If using Windows Server 2003 or older, you can open Drwtsn32.exe and check the Crash Dump path for the location. The file should typically be named ‘User.dmp’. Any dumps along with the MPS Report or MSDT logs should be uploaded to us for review.
- In both of these cases, the application in question will normally be NTVDM.EXE. This is the virtual machine environment for 16-bit applications.
Troubleshooting / Resolution: After you have gathered the data, there are some things to check:
- MPS Reports:
- Review the Event Logs for relevant events – specifically look for Event ID 26 (Application Popup), Event ID 1000 (Application Error) and Event ID 7034 (Service Control Manager) messages that correspond to the times that you are seeing unexpected application failures
- You should also check the Event Logs and Windows Update logs to see if there were any application updates or patches that preceded the unexpected behavior – there may be a correlation
- Process Explorer: If you have the opportunity to do so, it may be worth using Process Explorer to examine what an unresponsive application is doing while it is in-state
- Dump File Analysis: If you are experienced at looking at dump files, there are some things that you can look for
- For hang dumps, check for application locks (for example, anti-virus locks), long-running threads and whether or not the application is waiting for data – for example from a network resource or a user input
- For application crash dumps, running the command !analyze -v may provide a hint as to the cause of the failure. However, the output of this command may not always identify the real culprit.
Finally – where the application in question is either a custom in-house application or a third-party (non-Microsoft) application, you should always engage either your developer or the application vendor for assistance. The reason for this is that we do not have access to the application’s source code or symbols – so our debug analysis may be incomplete. If the application is an in-house application (for example a .NET application) you should open a case with our developer support group for assistance.