Troubleshooting Visual C++: Setup and Build Process
ID: Q102333
|
The information in this article applies to:
-
Microsoft Visual C++ for Windows, 16-bit edition, 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).
- Close Windows. Do not modify AUTOEXEC.BAT or CONFIG.SYS at this
time. Shutdown and reboot your system.
- If you run an MS-DOS shell program, close the shell.
- Verify the MS-DOS environment variable settings. If necessary,
run the MSVCVARS.BAT file in the MSVC BIN (by default,
C:\MSVC\BIN) directory.
- Make the MSVC HELLO Microsoft Foundation Class sample directory
(by default, C:\MSVC\MFC\SAMPLES\HELLO) the current directory.
- 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.
- 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.
- Shutdown and reboot your system to restore its original
conditions. Then start Windows.
- Open a full-screen MS-DOS session.
- Repeat steps 1c through 1f above. A failure here indicates an
interaction between MS-DOS and Windows or a conflict with the
Windows settings.
- Close the full-screen MS-DOS session and open an MS-DOS window.
- 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.
- 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.
- Open the HELLO.MAK project and build it. Open the WINTEER icon.
- 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
Version :
Platform :
Issue type :
Last Reviewed: August 5, 1999