Q: What is "Exception #13"? Q: What can be done to prevent "Exception #13"s? Exceptions are unusual or invalid conditions associated with the execution of a particular instruction by the 80386 processor (or higher processors). The 80386 recognizes several different classes of exceptions, and assigns a different vector number to each class. The DESQview-386 memory manager, QEMM-386, has been designed to capture these 80386 exception vectors and display them directly to the user. Exception #13 is the "General Protection Fault" error. Any privileged instruction or any instruction that references memory can trigger an Exception #13. In the first case, privileged instructions, the Exception #13 could indicate that a program has violated the protected mode of the 80386 by executing a privileged instruction or I/O reference. Thus, when the prompt, "Terminate, Reboot or Continue?" is issued, the "Continue" option puts the system back into real mode, and the program should continue to (15 left) More: (Enter) or (Y)es, (N)o, (NS)non-stop? ns execute. (After choosing the "Continue" option, one should not necessarily assume that the system is stable. A reboot at the earliest convenient time is probably wise.) It is the second case, instructions that reference memory, that is far more common to DESQview 386 (and QEMM-386) users. Here the exception may indicate that an application has a bug, or that adverse circumstances have sent it out of control. It has over-written its memory partition, and may in fact be running wild, writing code all over the place. This situation can occur with some programs that were written for use on the 8088 processor and may not be usable in the 80386's virtual 8086 mode. A few other programs may not be compatible with QEMM-386. In some cases the problem occurs even without QEMM present (in which case it manifests itself as a crash instead of an an error message). What this usually adds up to is that when "Terminate, Reboot or Continue" is displayed, the user can usually only "Terminate." For those users who are more technically oriented, this over-writing of the memory partition generally means that a word or a double word value of code has been written to the last byte of a segment. The problem or "bug" in the application program or in the system shows up as an attempt to wrap the value to the next segment of memory. What can the user do to prevent Exception #13's? Because a great many problems can result in Exception #13's, it is sometimes necessary to resort to general troubleshooting techniques. The DESQview 386 user should start with two simple steps: first, run Change a Program and try to allocate more memory to the application. Second, the user can try to increase the protection level of the afflicted window to 3, which will not remove the source of the Exception #13, but may pass more descriptive error messages through to the user. When Exception #13's are obtained outside of DESQview they are either caused by applications written for the 80386 protected mode or they are not. If the faulting application is written for the protected mode of the 80386, it is likely that this program has no VCPI (Virtual Control Program Interface) support. Since QEMM-386 is a protected mode program, such faulting applications cannot be run under QEMM without VCPI. The user has no choice but to reboot without QEMM, and contact the developer of the faulting application to request VCPI support. If the faulting application was not written for the protected mode of the 80386, a good possibility is that the QEMM user has installed QEMM with the RAM parameter (which is necessary to LOADHI drivers and TSR's). In this case the faulting program may be running in an area of high RAM that contains a memory conflict. To correct this problem, the user may opt to RAM only specific areas of memory, as described on page 6 of the QEMM-386 manual, rather than to RAM all mappable areas. Of course, an area of conflict that is not RAMmed is still an area of conflict, and may cause problems if another application tries to map expanded memory into that region. A better solution to such memory conflicts might be to use the EXCLUDE parameter (described on page 5 of the QEMM manual) on the area in conflict. When in doubt about which areas to exclude, the user may wish to pay special attention to areas that are marked "Rammable" on the QEMM.COM Type screen, or to High RAM areas in the F000-FFFF area. "Rammable" areas are usually adjacent to ROM areas, and the possiblilty exists that the ROM is slightly bigger than QEMM could detect and is spilling over into the "Rammable" area. High RAM areas in the F000-FFFF region are mapped over pieces of the system ROM that either QEMM or the user have judged not to be in use. Obviously, this judgment should be questioned when Exception #13 messages occur. The F000-FFFF area should be scrutinized especially carefully when floppy disk access generates the exception error. The QEMM.COM Accessed screen (also available as the Manifest QEMM- 386\Accessed screen) can give the user valuable hints about what areas of memory are in use. To use the Accessed screen, replace the RAM parameter on the QEMM line in the CONFIG.SYS file with the ON parameter and reboot the machine. Any area that the Accessed screen then shows as having been touched, but that the Type screen shows as Mappable or Rammable, is a good candidate for exclusion. If the Exception #13 error only occurs with the RAM parameter present, you can now safely perform the action that usually generates the error, then consult the Accessed screen to see what areas of memory have been newly touched. Some pieces of hardware can come into conflict with QEMM or DESQview and generate Exception #13 errors. The most frequent offenders are bus- mastering devices (hard disk controllers, network cards, CD-ROM controllers, etc.) and autoswitching video cards. Bus-mastering hard disk controllers often cause Exception #13 errors upon any use of the LOADHI programs, for instance. For approaches to this problem, see the Quarterdeck Technical Note titled "Bus-Mastering Devices and QEMM-386." Not all autoswitching video cards come into conflict with QEMM or other pieces of software. When a conflict occurs, however, it does not always take the form of a video problem, and sometimes results in the Exception #13 message. Disabling autoswitching is the only solution to such a problem. General troubleshooting methods, like temporarily removing all TSR's, device drivers and questionable QEMM parameters, often provide valuable information about the exception error. It sometimes happens that a circumstance that generates an Exception #13 with QEMM present simply causes the machine to crash without any message when QEMM is removed. In such a case, QEMM is simply the bearer of bad news. ************************************************************************** ID:WT Windows 3/QEMM386 Trouble-shooting Quarterdeck Technical Note by Stan Young QEMM-386 version 5.10 and above supports Windows 3.0 in all of its processing modes: Real, Standard and 386 Enhanced. The QEMM-386 upgrade booklet gives some specific instructions for the set up of QEMM-386 to ensure Windows compatibility. Most users who follow these instructions should find that Windows 3.0 will operate correctly with QEMM-386 in all three modes. For the most part, we have not seen problems which relate to QEMM-386 setup when running in Real or Standard modes. However, due to the broad range of hardware and software which may be combined in some systems, we have seen configurations which have experienced various problems when trying to run Windows 3.0 in 386 Enhanced mode. These problem include: Failure of Windows to start up in Enhanced mode, system crashes when exiting Windows in Enhanced mode, and in some cases problems while running Windows which do not occur when you are not loading QEMM-386. IF WINDOWS 3.0 WILL NOT START IN ENHANCED MODE OR CRASHES ON EXIT: Initial Check List: The first thing to do if you are having trouble starting Windows 3.0 in Enhanced mode, or upon exit from Windows, is to check your system to be sure that it has been set up as suggested in the QEMM 5.1 Upgrade Booklet. Following are some items that are important to Enhanced mode operations. 1. Be sure the statement which loads QEMM-386 in your CONFIG.SYS file is using the "RAM" parameter or that if you are not using the RAM parameter, you should use "X=B000-B7FF" to exclude QEMM's use of the monochrome video area. Additional information on this is given in the Upgrade Booklet on page 4. 2. If you are running on a machine which has different speeds of memory, you will need to use the NOSORT (NS) parameter. If you are running on a machine which would normally have less than 640K of conventional memory and where QEMM-386 is filling the memory to 640K, you must use the NOFILL (NO) parameter. In both these cases, QEMM-386 cannot support these features while Windows 3.0 is in Enhanced mode. This is because QEMM-386 must be in an "ON" state to manage these sorted memory and memory filling. Windows turns QEMM-386 "OFF" when it starts up in Enhanced mode. QEMM-386 does not have to be turned off when Windows is in Real or Standard modes, therefore machines that required these features could run in those modes. If you are not sure whether your machine has differing speeds of memory, or has 640K of conventional memory, try the parameters anyway. They will have no negative effect if they don't apply. 3. If you are running QEMM-386 version 5.10 instead of 5.11 or later and you have a machine, such as a PS/2 or microchannel compatible , which has an extended BIOS data area, you must use the NOXBDA (NX) parameter so that the extended BIOS data area will not be moved. QEMM-386 version 5.11 and later do not require this parameter and if you are a registered owner of QEMM 5.10, you may obtain an update, at no charge to version 5.11 by sending a request for the update to Quarterdeck along with your registered serial number. If you have not yet registered, you may request the update when you send in your registration card. Also, if you are getting paging errors from Windows, an upgrade to 5.11 may be necessary. PROBLEMS OR CRASHES WHILE RUNNING WINDOWS IN ENHANCED MODE: Problems or crashes which occur while running Windows 3.0 in Enhanced mode are typically not the fault of QEMM-386, because while Windows is in Enhanced mode, QEMM is completely disabled. In that state, QEMM-386 can neither cause problems or prevent them if they occur. However there may be changes to the system which QEMM-386 has made before being disabled which may later cause problems for Windows. If you encounter problems while running Windows, you should naturally consult with Microsoft Technical Support to see if they have a solution to the problem. If you suspect that QEMM-386 is somehow involved, try disabling QEMM entirely (by putting the word "REM" before the line which loads the QEMM386.SYS driver in your CONFIG.SYS). Leave all other resident programs or drivers installed and see if the problem persists. If it does, then the problem is not related to QEMM. If removing QEMM seems to correct the problem, restore QEMM and then try undoing some of the changes that QEMM has made. For instance, try loading QEMM, but do not load any of your resident programs into high RAM. Also, if you are using FILES.COM or BUFFERS.COM, try loading normal files and buffers. By the way, Windows 3.0 seems to require a minimum of at least 25 file handles, so if you are allocating fewer than 25, increase the number. WINDOWS 386 ENHANCED MODE CONFLICTS WITH OTHER SOFTWARE AND HARDWARE: Windows 386 Enhanced mode may have conflicts with certain types of hardware, or software which are not related to QEMM-386. These problems are best addressed by consulting with Microsoft or the manufacturers of the problem hardware or software. However, here are some of the areas where there might be conflicts: 1. NETWORKS Windows 3.0 currently supports ONLY the following networks: LAN Manager v1.0 or 100% compatibles LAN Manager v2.0 Basic or 100% compatibles LAN Manager v2.0 Enhanced or 100% compatibles Microsoft Network or 100% compatibles Novell Netware v2.1 or Netware 386* *Note: Use with Netware requires that you use 3.01 of the IPX and NETx software. Contact Novell for this. If your LAN is not one of the above or a compatible, then it probably will not work properly with Windows. Even if it is one of the above, there may be problems you may have to discuss with Microsoft or your LAN vendor. Network support has been one of the problem areas of the initial release of Windows 3.0. 2. EXPANDED MEMORY TSRs If you are using TSRs before Windows which use expanded memory ( disk caches, network drivers, ram disks or pop-up programs which swap themselves to expanded memory), these may not be compatible with Windows 3.0. Microsoft publishes a document for software developers that lists a number of EMS functions which may not be exercised by programs that are resident before Windows. In the past, some of these operations have been fairly commonplace, so it map prove that many TSRs that use expanded memory will be incompatible with Windows 3.0 -- at least in the enhanced mode. If you encounter problems running TSRs that use expanded memory before Windows 3.0, you should contact the manufacturer of the TSR to see if the EMS functions they use meet the limitations as outlined by Microsoft. 3. BUS-MASTERING DEVICES Bus-mastering devices are ones which do their own direct memory addressing (DMA). DMA is done without going through the machine's processor. The most common bus-mastering devices we see currently are SCSI hard disk controllers, but technically, other types of devices could be bus-mastering as well. The problem with these devices is that they put data into absolute memory addresses and assume that the contents of those memory addresses will always remain constant. However, when running Windows 3.0 in enhanced mode, this can often be an incorrect assumption. In Enhanced mode, the same physical memory addresses can, at any given moment hold different data, depending on which virtual machine is current. To run Windows 3.0 properly with these devices, you should obtain a driver from the manufacturer of the device which meets the VDS (Virtual DMA Services) specification. With such a driver, Windows 3.0 should be able to operate with your bus-mastering device. When you are not running Windows 3.0 in Enhanced mode, QEMM-386's DISKBUF (DB) parameter can be used to work around these problems. But again, since QEMM-386 must be disabled when Windows Enhanced mode is active, the DISKBUF parameter will have no effect. IF WINDOWS RUNS SLOWLY IN ENHANCED MODE: A full hard disk will probably impair Windows' paging ability and reduce the size and number of programs you can run in Windows. This symptom may look more pronounced with QEMM present. If your operations in Windows seem to be slower than they were previously, or you find yourself running out of memory, check to be sure you have plenty of free disk space. This should be at least 2MB (preferably more) on the drive that pointed to by the TEMP environment variable. Speed may also be affected by fragmentation of your hard drive and in these cases, setting up a permanent Windows swap file, as outlined on page 522 of the Windows manual might be useful. IF THE PRECEDING SUGGESTIONS FAIL: In particularly difficult cases getting Windows 3.0 to run in Enhanced mode, here are some things to check and try: 1. If the system has Shadow RAM, try QEMM-386's NOSHADOWRAM (NOSH) parameter. If you are not sure, try it anyway. The parameter will have no harmful effect if your system does not have Shadow RAM. 2. Try using the X=F000-FFFF parameter to exclude any QEMM mapping in the F000-FFFF area. 3. If, when starting Windows enhanced, you get a bunch of garbage on the display and beeping, and Windows goes back to the DOS prompt, check to see that there is a file called WINHIRAM.VXD in the QEMM directory, on your hard disk. Be sure also that this file is identical to the one on the disk that contains the version of QEMM that you are currently running. Versions of this file may be specific to the QEMM-386 version with which they shipped. 4. Run the Windows SETUP program from the DOS prompt,(not the Setup which runs inside of Windows) and be sure you have properly identified your machine to Windows. The default SETUP selection specifies "MS-DOS or PC- DOS System", and many users may tend to take this option. However, Windows provides specific setups for many common PC compatibles like AST, NCR, NEC, Toshiba, Everex, and Hewlett-Packard. Check this list if you are having problems. If your machine is on the list, use that selection. 5. Windows Enhanced mode may not like an EMS Page Frame at 9000. Check the location of the frame by running QEMM.COM. If the frame is at 9000, see if you can move it somewhere between C000 and E000. If 9000 was the default selected by QEMM, you may have to relocate installed hardware boards to free up a contiguous 64K memory block in high memory. Be careful you are not forcing the Page Frame over an installed device, or you will also have problems. If you have a Page Frame at 9000, problems are likely to show up when running DOS programs that use expanded memory in Windows 3.0 . 6. If you are running QEMM-386 v5.10 and have trouble running Novell's XMSNET, or anything that uses the XMS memory, before Windows enhanced, get the update to QEMM-386 v5.11. 7. In some cases the following modifications to the Windows 3.0 SYSTEM.INI file, which can be found in the WIN directory have proven to solve problems. Edit the file with a text editor (Windows Notepad will do) and following the line that says "[386Enh]", add a line which says "DualDisplay=True", followed by a line which says "EMMExclude=E000-EFFF". 8. Some users have reported that they don't get print options inside Windows. If you are having this problem, either remove the SET TEMP= environment variable that the Windows Setup program puts in your AUTOEXEC.BAT file, or make sure that the directory that it is pointing to actually exists and that there is space on the drive specified. 9. For problems running Windows standard or Windows real problems in DV, try changing our DVP's to load WIN /R or WIN /S instead of SYSTEM\KERNEL.EXE or SYSTEM\DOSX.EXE. Copyright (C) 1990 by Quarterdeck Office Systems * * * E N D O F F I L E * * *