Q102333 - Troubleshooting Visual C++: Setup and Build Process

Troubleshooting Visual C++: Setup and Build Process

Q102333

The information in this article applies to:

Microsoft Visual C++, version 1.0

Microsoft Visual C++ (MSVC) version 1.0 installs and runs correctly on most systems without any problems. However, on a small number of systems, serious post-setup problems occur, which may include system crashes or hangs, parity errors, time-out errors, and inability to complete the build operation. If you experience time-out errors from WINTEER, please see the following article in the Microsoft Knowledge Base:

Q112008 PRB: Visual Workbench Hang or Time-out Waiting for WINTEER.EXE

The text below describes a general troubleshooting technique to help narrow down the cases in which even a simple application cannot be built in the MSVC environment.

Visual C++ will most likely detect hardware and software conflicts if any exist on your system. Some hardware problems, such as a bad memory chip, a bad motherboard, or a bad disk controller, may cause conflicts with Visual C++.

Once you eliminate hardware problems, you need to search for software conflicts. Some software conflicts, such as third-party device drivers, Windows device drivers, network drivers, and terminate-and- stay-resident (TSR) applications may cause problems with Visual C++. Visual C++ uses memory heavily; running the compiler in Windows may cause Windows to allocate memory currently in use, such as that used by a third-party device driver, to Visual C++.

To narrow the range of possibilities, perform the following tests:

Run the compiler from MS-DOS. This technique has two advantages: it eliminates Microsoft Windows-related issues and, in most cases, the compiler works without any problems (however, memory issues may remain).
1. Close Windows. Do not modify AUTOEXEC.BAT or CONFIG.SYS at this time. Shutdown and reboot your system.
2. If you run an MS-DOS shell program, close the shell.
3. Verify the MS-DOS environment variable settings. If necessary, run the MSVCVARS.BAT file in the MSVC BIN (by default, C:\MSVC\BIN) directory.
4. Make the MSVC HELLO Microsoft Foundation Class sample directory (by default, C:\MSVC\MFC\SAMPLES\HELLO) the current directory.
5. At the MS-DOS prompt, type "cl /c hello.cpp" (without quotation marks) to compile only HELLO.CPP. If this step fails, the problem relates either to hardware or to MS-DOS software in the AUTOEXEC.BAT or CONFIG.SYS files.
6. If you can build HELLO.CPP, type "nmake /a /f hello.mak" (without quotation marks) to build the entire application. If this steps fails, it may be a hardware or MS-DOS problem. Edit your AUTOEXEC.BAT and CONFIG.SYS files to remove unnecessary device drivers and terminate-and-stay-resident (TSR) applications, shutdown and restart your system, and restart this procedure at step 1e above.

Run the compiler in an MS-DOS session in Windows. This step introduces the Windows settings but eliminates the effects of the MSVC build engine and of the WINTEER application.
1. Shutdown and reboot your system to restore its original conditions. Then start Windows.
2. Open a full-screen MS-DOS session.
3. Repeat steps 1c through 1f above. A failure here indicates an interaction between MS-DOS and Windows or a conflict with the Windows settings.
4. Close the full-screen MS-DOS session and open an MS-DOS window.
5. Repeat steps 1c through 1f above. If this step fails after step 2c above succeeds, most likely a Windows mouse or video conflict exists. Edit your AUTOEXEC.BAT and CONFIG.SYS files to remove any unnecessary device drivers or TSR programs. Modify your Windows installation to use the standard VGA driver and a minimal SYSTEM.INI file.

Test the Visual C++ environment.
1. Start MSVC with the /V option switch to set the properties. For more information on the /V switch, please refer to the README.WRI file in the README viewer.
2. Open the HELLO.MAK project and build it. Open the WINTEER icon.
3. If that fails, close MSVC and start it again with the /R and /V switches. At this point, it may be necessary to remove unnecessary device drivers or TSR programs from AUTOEXEC.BAT, CONFIG.SYS, and SYSTEM.INI. A report from the MSD utility may be useful to help identify and resolve conflicts.

When you start Windows, you can specify two switches that sometimes prevent memory conflicts. If either of these switches eliminates the problems you encounter, you can edit your SYSTEM.INI file to make them a part of the Windows start-up process. According to the Windows online help, the switches are of the form /D:<a>, where <a> is one of the following:

F Turns off 32-bit disk access Equivalent to the SYSTEM.INI file setting: 32BitDiskAccess=FALSE

S Specifies that Windows should not use the ROM address space between F000:0000 and 1MB as a break point. Equivalent to the SYSTEM.INI file setting: SystemROMBreakPoint=FALSE

V Specifies that the ROM routine handles interrupts from the hard disk controller. Equivalent to SYSTEM.INI file setting: VirtualHDIRQ=FALSE

X Excludes all of the adapter area from the range of memory that Windows scans to find unused space. Equivalent to SYSTEM.INI file setting: EMMExclude=A000-FFFF

For additional information about creating a SYSTEM.INI file that does not include third-party device drivers, please see the following article in the Microsoft Knowledge Base:

Q117674 How to Create SYSTEM.INI Without Third-Party Drivers

Another good method to test for video driver problems involves checking if the driver can produce output in a "background MS-DOS session" while output occurs in the Windows screen. To do so, start an MS-DOS session and run the following batch file:


   :again
   dir
   goto again

Choose Settings from the MS-DOS window system menu and choose Background.

While the batch file runs in the background, start an application developed for the Windows operating system. If a System Integrity Error occurs, the video driver may conflict with Visual C++.

Additional query words: kbinf 1.00

Keywords : kb16bitonly
Issue type :
Technology : kbVCsearch kbAudDeveloper kbvc100