CL Command-Line Error D2030

Message Text

    Please choose the Technical Support command on the Visual C++
    Help menu, or open the Technical Support help file for more information


Error D2030 has two broad causes: internal and external.

Fault in CL.EXE

One cause of error D2030 is an access violation, most likely in the CL.EXE code, but anyway left unhandled until it reaches CL’s top-level exception handler. In this case, CL is itself the cited component (given as a full pathname in typical practice, with CL executed from the Command Prompt).

The /Bd and /Bz options each act to defeat this handler. Provided the access violation does not occur too early, i.e., before CL has acted on those options, it does not cause error D2030, but instead passes from CL as an unhandled exception. This has the advantage in practice of making readily available such details as the faulting address, typically with an offer to send a report to Microsoft over the Internet.

As it happens, error D2030 is easily induced during the parsing of options, though admittedly with the contrivance of using an option that is undocumented (being very plausibly very long obsolete). The command

cl /otest1.exe /Fetest2.exe 

suffices. It doesn’t matter that no input files are given. Long before input files are sought, the /Fe overrides the /o, but the cleanup is done incorrectly, so that CL later dereferences a null pointer.

Unspecified Error in Compiler Module

The other cause of error D2030 is that CL has executed the cited component as a compiler module, which then returned the specific value 0x020D, either as its exit code (if the module is an executable program) or as the result of its _InvokeCompilerPass@12 function (if the module is a DLL). Note that the pathname given for component is what CL used for the module when spawning or loading it.

It seems safe to presume that the intention is to provide for a module to encounter an error but leave CL to produce some standardised description. However, no compiler module supplied with Microsoft Visual C++ seems to avail itself of this provision: all have substantial error handling of their own.

Confirmation by example is nonetheless easily arranged. Build a program TEST.EXE whose main function simply returns 0x020D, then use the /B1 option to name TEST.EXE as a replacement for the usual front-end C compiler. The command

cl /B1test.exe test.c

then produces error D2030.