I encountered a Visual Studio 2008 bug this morning that had me baffled. The short summary is that, in a C++ source file with multiple #ifdef blocks, only the first block was properly displaying in gray for the deliberately undefined symbol. Subsequent blocks were showing up in color, even though they used the same symbol as the first block. In addition, mouse hovers didn't display values after a certain point i I encountered a Visual Studio 2008 bug this morning that had me baffled. The short summary is that, in a C++ source file with multiple #ifdef blocks, only the first block was properly displaying in gray for the deliberately undefined symbol. Subsequent blocks were showing up in color, even though they used the same symbol as the first block. In addition, mouse hovers didn’t display values after a certain point in the file. The project built fine, however.It was a weird enough symptom that I emailed someone on the Visual Studio team about it to ask if it was a known problem. He was at the launch event, but he forwarded my email to a few other people, who forwarded it to a few more people, until finally someone responded: Hi Martin, The most probable cause is one of two things: you are using this file in a solution where it is included by multiple projects/files with different macro contexts. In VS2008 we can only interpret the file once in one context (something we’ve fixed in the next release). The other reason is that you have not specified the full set of macros but I doubt it since you say it builds. If you can isolate this into a small repro, we’d be happy to look at it. It wasn’t either of those problems. When I went to try to isolate a minimum set of files to reproduce the problem, however, I was surprised by what I found. As I wrote back: I’ve isolated the problem. I’ve also fixed it for now. In the original ATL project, the CPP file correctly showed the first block that had been #ifdef’d out in gray, but showed subsequent blocks #ifdef’d out using the same name in color. Also, every symbol below a certain point was treated as undefined, even very common symbols like S_OK. I created a new ATL project, added the problematic CPP file to it, and brought it up for editing. Once the IDE had processed the file, and before I tried to compile, the #ifdef’d blocks all displayed in gray as I expected, and all expected symbol values displayed properly on a mouse hover. When I switched back to the original project, I immediately saw a message in the output box on the order of “can’t open source database,” along with some irrelevant suggestion about it being open in another project. (If this message was there before, I didn’t notice it.) I closed devenv, deleted the .NCB file for the solution, and reopened the solution. After a pause, all was well. I remember corrupted .NCB files being a recurrent, nagging problem in Visual Studio .NET, but I thought that was behind us. Apparently it’s still an issue in VS08. The response was good news: Indeed, the frequency of the problem has been greatly reduced but given the difficulty in reproducing those problems, we can never be sure to remove it completely. You’ll be happy to know that our next release has completely overhauled this architecture and we’ll be able to safely say that this type of thing won’t ever occur again. Needless to say, I’m looking forward to Visual Studio 2008 SP1. Software Development