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:
Troubleshooting / Resolution: After you have gathered the data, there are some things to check:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.