Fooling Around

Having installed Visual Studio .NET 2008 Service Pack 1 (installs Windows SDK 6.0a) and Windows SDK 6.1, I would obviously like to have newer Windows SDK used in include path. However after edit of WindowsSdkDir environment variable and checking all include directories to point to new Windows (former Platform) SDK path “C:\Program Files\Microsoft SDKs\Windows\v6.1“, MIDL compiler still looked for files in wrong directoty, why?

1>Microsoft (R) 32b/64b MIDL Compiler Version 7.00.05001>Copyright (c) Microsoft Corporation 1991-2006. All rights reserved.
1>Processing .\MyProject.idl
1>MyProject.idl
1>Processing C:\Program Files\Microsoft SDKs\Windows\v6.0a\include\dispex.idl
1>dispex.idl
1>Processing C:\Program Files\Microsoft SDKs\Windows\v6.0a\include\ocidl.idl
1>ocidl.idl
...

A quick check of devenv.exe process environment variables revealed mystic names _ACP_ATLPROV, _ACP_INCLUDE, _ACP_LIB, _ACP_PATH defined by Visual Studio environment itself and they don’t seem to be configurable through some file in Visual Studio directory.

However the solution came rather quickly. The older SDK directory has to be referenced from somewhere for the Visual Studio to pick it up. Installed Widnows SDK versions are listed in registry under key HKEY_CURRENT_USER\Software\Microsoft\Microsoft SDKs\Windows, a subkey for each version, and it was older SDK set to be current.

Once switched to new there, MIDL compiler started taking include files from proper directory.

Some time ago I faced an annoying problem with a freeze of Visual Studio opening a solution with a Setup Project. I found that the problem was related to setup projects (.vdproj) that time and it was something with Visual Studio update, but I was of an opinion that Visual Studio .NET 2008 has problems opening projects created by version 2005. Compatibility or something… however the problem appeared that it cannot even create a new Setup Project with again a freeze.

Luckily, I found a hint on MSDN Forums, and although the solution/workaround was not detailed enough, it worked for me from the first guess. Here it goes:

1. Start Component Services (dcomcnfg) from command line
2. Right-click My Computer, and click Properties:

   

   In the popped up window uncheck additional security box:

   

It appears to be sufficient for the Visual Studio .NET 2008 to start loading .vdproj projects again.

A picture for relaxation:

It is probably a fresh bug there as it seems to be happening far more frequently with version 2008 (with ot without SP1) as compared to 2005. Luckily it has no effect to code being written, the problem clearly relates to debugger. At some point there is a crash, though which the IDE perfectly survives but longer can start a new debugging session until IDE is entirely restarted.

It is amazing how bugs go through versions and years. Visual Studio’s IDE dockable windows framework is cool, no doubt. But it was since 2005, if not earlier, that tool window undocked by a double click while application is running (debugging session active) is brought to wrong position and is tending to go out of screen area being re-shown.

This is exactly the behavior in 2008 version, regardless of reworked framework and fancy icons/hints/placeholders for the window being dragged. But just now it was even better. I double clicked “Find Results 1″ window to maximize the window… and it disappeared. After looking for it through menu and other GUI elements, I finally found it at the rightmost border of the secondary monitor:

The other day I “wrote some code” to workaround an extremely stupid hardware issues. The depth of idiocy is just incredible: to release a bunch of hardware that just don’t work, release a number of firmware updates that just don’t fix the simplest thing: HTTP compatibility. If there was a single little try to see how this piece of crap comminicates with any WinHTTP based application, an error 12152 ERROR_WINHTTP_INVALID_SERVER_RESPONSE on the first second of execution would imminently come up and demonstrate that someone has to be fired without any hesitation.

Things, however, definitely went a different way with hardware still on the shelves and no firmware upgrades available on the website. Our customer got into trouble having already recommended his customer the buggy thing in amount of X and forwarded us the question of getting everything working. As we decided to make a step towards, I needed to “write some code” to settle the problem.

However, the story was about a different thing. So in order to put a comment into code that explains what kind of problem we are dealing with, I copy/pasted a fragment of HTTP request/response content from Wireshark into source file being edited within MS Visual Studio .NET IDE. Wireshark copies text with some weird line endings, I knew that. I removed extra empty lines from pasted text and actually did not expect anything to go wrong. However who appeared to be wrong was me.

Initially there seemed to be no problem, I tried to compile code, fixed some compiler errors, even started application. I was somewhat confused that the application did not hit my breakpoint while it should. Then I noticed it did not even generate code for this line. As these things do happen with development environment, I re-opened IDE, deleting .NCB for the project and Rebuilt All. The problem however did not go. After further code modification, the compiler started giving errors and shown wrong lines in build output, which did not match source code line numbers.

This started being completely stupid: I was to look at wrong identifier, search through entire source file for occurrences, see if this particular occurrence might be actually a problem for compiler and so on. I made it compiled successffully but under debugger there were still wrong line numbers which made it impossible to debug and set breakpoints.

At this point I remembered Wireshark and line endings. Just removing the comments did not worked. And since visually everything was OK with the source, there should be an easy way found to normalize text. And what I did was the following: I started new message in Mozilla Thunderbird and copy/pasted entire source file content into Thunderbird’s editor. Then copy/pasted back into Visual Studio and finally got the things fixed.

Version 2008 (9.0) of Microsoft Visual Studio .NET 2008 Service Pack 1 development environment brings new annoyances in. It seems to be still freezing and crashing on certain source code files, just as previous versions did and additionally there is a new trick in:

A termination of debugged application quite often ends up with a crash. Once crashed, IDE is still alive (thanks, really) but no debugging session will ever start again. A restart of IDE is required. Posted a crash report once again, hopefully someone is receiving them on MS side and takes to consideration.

Another weird bug from Visual C++ .NET/ATL internals (Visual Studio .NET 2003 Service Pack 1). IDispatch implementation (IModuleCommunicationTcp on the screenshot) supplied by Visual C++  compiler that converts “by DISPID” IDispatch::Invoke call into virtual method call (IModuleCommunicationTcp::get_HttpHost) does not initialize local BSTR variable i1 on stack. In case of method failure (in which case there is no guarantee i1 was properly initialized/cleared) the code still uses the variable to initialize VARIANT.

In my case this caused resulting VARIANT (CComVariant) contain .vt = VT_BSTR, .bstrVal = 0×00000002, which is obviously incorrect and caused an access violation exception later in VariantClear call.