Published by alax on 24 Sep 2008

Microsoft Visual Studio .NET 2008 SP1 IDE bugs continued

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:

Published by alax on 15 Sep 2008

Microsoft Visual Studio .NET Development Environment

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.

Published by alax on 07 Sep 2008

New Visual Studio .NET 2008 annoyances

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.

Published by alax on 11 Apr 2008

Yet another ATL bug

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.

Published by alax on 29 Mar 2007

STRING resource problem/bug (SetThreadLocale, _CONVERSION_DONT_USE_THREAD_LOCALE)

There has been an unexpected problem localizing application resources when STRING resources failed to load while there were no problems with other resource types. The source of the problem appears to be within ATL core. As long as CP_THREAD_ACP is involved in ATL’s conversion the loaded string is screwed.
The problem is illustrated by the sample. The same string resource is loaded with LoadString API and CString::LoadString ATL function. The difference is emphasized with bold below. As soon as Russian string is loaded from a thread with non-Russian thread locale, the string is screwed but only when loaded through ATL class (warning: Russian characters seems to be forged by WordPress in quoted text below):

C:\>ThreadLocaleSample01.exe
Default Thread Locale: 1033 (0×409), Primary Language 9 (0×9), SubLanguage 1 (0×1), Sort 0 (0×0)
String 101: ABCDEFGHIJKLMNOPQRSTUVWXYZ
String 102: ????????????????????????????????
ATL String 101: ABCDEFGHIJKLMNOPQRSTUVWXYZ
ATL String 102: ????????????????????????????????
Russian Locale: 1049 (0×419), Primary Language 25 (0×19), SubLanguage 1 (0×1), Sort 0 (0×0)
String 101: ABCDEFGHIJKLMNOPQRSTUVWXYZ
String 102: ????????????????????????????????
ATL String 101: ABCDEFGHIJKLMNOPQRSTUVWXYZ
ATL String 102: ????????????????????????????????
English Locale: 1033 (0×409), Primary Language 9 (0×9), SubLanguage 1 (0×1), Sort 0 (0×0)
String 101: ABCDEFGHIJKLMNOPQRSTUVWXYZ
String 102: ????????????????????????????????
ATL String 101: ABCDEFGHIJKLMNOPQRSTUVWXYZ
ATL String 102: ????????????????????????????????

Continue Reading »