Internal Compiler Error (file msc1.cpp line 2701) in ATL COM project

[Michael Kennedy [UB]]

Hi,

I would like to report some weird behavior which results in an internal
compiler error in VS.NET 2003 (VC++).

I have an ATL COM dll project which also uses MFC. This solution (workspace
at the time) was created in VS 6.0 using the current versions of ATL and MFC
at that time. Then it was upgraded to VS.NET 2002 and the respective
versions of ATL and MFC. So far everything has been fine.

Now I tried to compile this project in VS.NET 2003 and there is some very
strange behavior. Rebuilding the entire solution results in this message:

fatal error C1001: INTERNAL COMPILER ERROR compiler file msc1.cpp line
2701

I discovered that if I change the stdafx.h file to use windows version 0x500
(see listing below) then it compiles OK. But it seems like I should be able
to keep it at 0x400. Stanger still, if one of _WIN32_WINNT and WINVER is
0x400 and one is 0x500 (can't remember which was which) then it compiles in
DEBUG but results in the compiler error in RELEASE.

Does any one know how to get around this? Is this a known issue?

Thanks in advance,
Michael

------------- stdafx.h -----------------------
#define STRICT
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0500
#endif

#define WINVER 0x0500

#include <afxwin.h>
#include <afxdisp.h>

#include <atlbase.h>
//You may derive a class from CComModule and use it if you want to override
//something, but do not change the name of _Module
extern CComModule _Module;
#include <atlcom.h>
---------------------------------------------

 

[Zach Kramer]

Michael,

I am not sure exactly what is going on here. The best thing would be to
take a look at a preprosser file. This will contain a reproduction of the
compilation issue. To do this perform the following steps:

1. Select the file that is generating the C1001.
2. Right click on the file and select the properties for the file
3. Under "C\C++->Command Line" and add /I (that is a capital i) to the
Additional Options.
4. The right click on the file and compile the file.

This will generate a .I file of same name as the file that you just
compled. You can zip up this file and e-mail it to me (just remove online
from the address).

We can take a look at his and see if this is a known issue and what a
possible work around is.

I am not sure exactly what the different #defines are including or
excluding to prevent the error. Since all that a C1001 tells us is that
this is a compiler error that the compiler did not handle it does not tell
us a whole lot. The preprossor file will tell us more. Let me know.

Thanks,
Zach

Microsoft PSS
(e-mail address removed)

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Zach Kramer]

One quick correction. Step 3 was incorrect:

3. Under "C\C++->Command Line" and add /I (that is a capital i) to the
Additional Options.

It should be:

3. Under "C\C++->Command Line" and add /P (that is a capital p) to the
Additional Options.

I apologize for the mistake.

Thanks,
Zach
Microsoft PSS
(e-mail address removed)

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Michael Kennedy [UB]]

Hi Zach,

Thanks, I've been trying to get the compilation going per your instructions.
I was having a tough time getting /I to generate any files! I'll retry it
and get back to you.

Regards,
Michael

 

[Brett Keown [MSFT]]

Hi Michael,

Thanks again for using the Microsoft Newsgroups! I wanted to find out if
Zach's previous reply has resolved your problem or not. Can you provide
the community with an update to your issue please?

Thanks again,

Brett Keown
Microsoft Support
(e-mail address removed)

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Michael Kennedy [UB]]

Hi Brett,

Here's what I can tell you about the status of this issue.

Zach was able to reproduce the problem using some of the compiler output
that I generated per his instructions. Currently Zach is looking into the
cause of the problem.

Has this resolved my problem? Not really. But I assume it is being looked
into since it is a reproducible, fatal compiler error. Once I have a
work-around or a service pack for VS.NET 2003 with a fix then the problem
will be resolved. I don't expect either of those any time soon. I'll try to
post any more information I receive to this thread.

Regards,
Michael