A colleague pointed out that code snippet in previous post is misusing ATL’s ATLENSURE_SUCCEEDED macro making it [possibly] evaluate its argument twice in case of failure, that is evaluating into failure HRESULT code. As it is defined like this:

#define ATLENSURE_SUCCEEDED(hr) ATLENSURE_THROW(SUCCEEDED(hr), hr)

It does things in a straightforward way, for a code line

ATLENSURE_SUCCEEDED(pFilterGraph.CoCreateInstance(CLSID_FilterGraph));

It is doing “let’s CoCreateInstance the thing and if it fails, let’s CoCreateInstance it again to find out error code”. Disassembly shows this clearly:

This is exactly another spin of the story previously happened with HRESULT_FROM_WIN32 macro and possibly a number of others. With it being originally a macro, SDK offered an option to override the definition by pre-defining INLINE_HRESULT_FROM_WIN32. This way a user might be explicitly requesting a safer definition while still leaving legacy code live with macro. See more detailed story on this in Matthew’s blog.

A tricky thing is that with successful execution the problem does not come up. In case of failure, it depends on the functions called, some with just repeat the error code, some will return a different code on second run, some might create less desired and expected consequences. So you can find yourself having written quite some code before you even suspect a problem.

Having identified the issue, there are a few solutions.

1. First of all, the original ATLENSURE_SUCCEEDED macro can still be used, provided that you don’t put expressions as arguments.

This is going to do just fine:

const HRESULT nCoCreateInstanceResult = pFilterGraph.CoCreateInstance(CLSID_FilterGraph);
ATLENSURE_SUCCEEDED(nCoCreateInstanceResult);

2. Second straightforward way is to replace the original ATL definition in ATL code (boo, woodenly)

3. As ATL code is checking for the macros to be already defined, and skipping its own definition in such case, it is possible to inject a safer private definition before including ATL headers (which would typically need one to do the define in stdafx.h):

#define ATLENSURE_SUCCEEDED(x){ const HRESULT nResult =(x); ATLENSURE_THROW(SUCCEEDED(nResult), nResult); }

#include <atlbase.h>
#include <atlstr.h>

Pre-evaluating the argument into local variable is going to resolve the original multi-evaluation problem.

4. There might be a new inline function defined on top of the original macro, which will be used instead and which is free from the problem:

inline VOID ATLENSURE_INLINE_SUCCEEDED(HRESULT nResult)
{
    ATLENSURE_SUCCEEDED(nResult);
}

Either way, the correct code compiles into single argument evaluation and throws an exception with failure code immediately:

Also, vote for the suggestion on Microsoft Connect. The issue is marked as fixed in future version of Visual Studio.

If you dare to convert your C++ ATL Service project created with an earlier version of Visual Studio to version 2010, as I recently did, you might find yourself surprised with why the hell the bloody thing does not work anymore as a regular executable.

After passing compiler/linker and SDK update issues, which you possibly might have too, the started executable will stumble on ATL error/exception with CO_E_NOTINITIALIZED (0x800401F0 “CoInitialize has not been called.”). Luckily the error code is good enough for quickly locating the problem and the reason is that the one you trusted, that is ATL, introduced an small improvement which is good for running as service but it not initializing COM anymore if you run your .EXE in application mode.

The bug is on MS Connect since August 3, 2010 closed as if it is going to be fixed some time in future when the fix is propagated to end developers. If you are in a rush and would like to write some code before the event, here are the details.

Previously, COM was initialized right in module constructor, in CAtlExeModuleT. CAtlServiceModuleT class just inherited from there. Later on, someone smart decided that it was not so cool and moved initialization to a later point into CAtlExeModuleT::WinMain. Well, this makes sense as you might (a) end up not needing COM at all, or (b) you want to do some important things before even initializing COM.

Unfortunately, the fact that CAtlServiceModuleT is inherited and relies on base class was not paid too much attention. CAtlServiceModuleT is not getting COM initialization from constructor any longer, CAtlServiceModuleT::WinMain is overridden in full and does not receive initialization from new location either. So well, it does not receive it at all unless run as service, which code execution branch looks still heatlhy here and exhibits another issue later soon.

To resolve the problem, the fragment in CAtlServiceModuleT::Start needs the correction as shown below (within #pragma region):

        if (::StartServiceCtrlDispatcher(st) == 0)
                m_status.dwWin32ExitCode = GetLastError();
            return m_status.dwWin32ExitCode;
        }

        // local server - call Run() directly, rather than
        // from ServiceMain()
        #pragma region Run wrapped by InitializeCom/UninitializeCom
        // FIX: See http://connect.microsoft.com/VisualStudio/feedback/details/582774/catlservicemodulet-winmain-coinitialize-not-called-800401f0
#ifndef _ATL_NO_COM_SUPPORT
        HRESULT hr = E_FAIL;
        hr = T::InitializeCom();
        if (FAILED(hr))
        {
            // Ignore RPC_E_CHANGED_MODE if CLR is loaded. Error is due to CLR initializing
            // COM and InitializeCOM trying to initialize COM with different flags.
            if (hr != RPC_E_CHANGED_MODE || GetModuleHandle(_T("Mscoree.dll")) == NULL)
                return hr;
        } else
            m_bComInitialized = true;
        m_status.dwWin32ExitCode = pT->Run(nShowCmd);
        if (m_bComInitialized)
            T::UninitializeCom();
#else
        m_status.dwWin32ExitCode = pT->Run(nShowCmd);
#endif
        #pragma endregion 

        return m_status.dwWin32ExitCode;
    }

Going further from there, the introduced optimization also removed COM initialization from main process thread module Run function. Provided there earlier too through module constructor it is not longer there. So if you are doing something in application’s run when the application is set to run as service and is executed in application (where you might want to start application as a sort of a helper, or otherwise in specific mode), you need COM initialization there too.

It might be something like this:

class CFooModule :
    public CAtlServiceModuleT<CFooModule>
{
// [...]
    HRESULT Run(INT nShowCommand = SW_HIDE) throw()
    {
// [...]
            if(m_bServiceHelper)
            {
                // NOTE: Starting with Visual Studio 2010 service helper's Run receives no automatic COM initialization any longer
                nResult = InitializeCom();
                if(SUCCEEDED(nResult))
                {
                    nResult = __super::Run(nShowCommand);
                    UninitializeCom();
                }
            } else
                nResult = __super::Run(nShowCommand);
// [...]
    }
// [...]
};

Having done that we are really closer but there is still another breaking bug in ATL caused by Visual Studio 2010 changes. You start a service and its endlessly shown as being started.

It appears that ATL is failing to call SetServiceStatus(SERVICE_RUNNING) to indicated startup completion and service healthy state. Again, the bug is related to change in base class behavior. This time, the problem is caused by the fact that SetServiceStatus call was moved from CAtlServiceModuleT::Run into CAtlServiceModuleT::PreMessageLoop. However, it was moved into the section conditionally compiled with definition of _ATL_FREE_THREADED. If you are and old school guy with _ATL_APARTMENT_THREADED instead and is just converting and older project that worked before, you have a problem here again: you have to add missing call.

To fix this, the end of CAtlServiceModuleT::PreMessageLoop should be looking like this:

#else
        hr = CAtlExeModuleT<T>::PreMessageLoop(nShowCmd);

        #pragma region Missing SetServiceStatus
        if (m_bService)
        {
            LogEvent(_T("Service started/resumed"));
            SetServiceStatus(SERVICE_RUNNING);
        }
        #pragma endregion 
#endif // _ATL_FREE_THREADED

#endif    // _ATL_NO_COM_SUPPORT

        ATLASSERT(SUCCEEDED(hr));
        return hr;

Well, this is embarrassing.

If you share concept (as I do) that every build should have a unique file version stamp in it, for a simple purpose – at least – to distinguish between different version of the same binary, then a helpful tool of automatic incrementing fourth number in FILEVERSION’s file version is something you cannot live without. After going through several fixes and updates, it is finally here available for download.

The last issue was in particular that projects that are in solution’s folder are not found by the add-in with Visual Studio 2008. Why? OnBuildProjConfigBegin event provides you with a unique project name string in Project argument, but it appears that it is only good enough as a quick lookup argument with Visual Studio 2010.

// EnvDTE::_dispBuildEvents
    STDMETHOD(OnBuildBegin)(_EnvDTE_vsBuildScope Scope, _EnvDTE_vsBuildAction Action) throw()
    STDMETHOD(OnBuildDone)(_EnvDTE_vsBuildScope Scope, _EnvDTE_vsBuildAction Action) throw()
    STDMETHOD(OnBuildProjConfigBegin)(BSTR Project, BSTR ProjectConfig, BSTR Platform, BSTR SolutionConfig) throw()
    {
        _Z4(atlTraceCOM, 4, _T("Project \"%s\", ProjectConfig \"%s\", Platform \"%s\", SolutionConfig \"%s\"\n"), CString(Project), CString(ProjectConfig), CString(Platform), CString(SolutionConfig));
        _ATLTRY
        {
            // NOTE: const CString& cast forces compiler to process statement as variable definition rather than function forward declaration
            CProjectConfiguration ProjectConfiguration((const CString&) CString(Project), CString(ProjectConfig), CString(Platform), CString(SolutionConfig));
            CRoCriticalSectionLock DataLock(m_DataCriticalSection);
            // NOTE: Check the project on the first run only (to skip multiple increments in batch build mode)
            if(!Project || m_VersionMap.Lookup(ProjectConfiguration))
                return S_FALSE;
            _Z3(atlTraceGeneral, 3, _T("Checking project \"%s\"...\n"), CString(Project));
            // Checking the project is of C++ kind
            CComPtr<EnvDTE::Project> pProject = GetProject(CComVariant(Project));
            _A(pProject);
            ...

When the project is in a folder, Projects::Item can just fail if you are looking up for the element interface. In which case, you have to walk the collection taking into account SubProjects and additionally look there yourself. Visual Studio 2010 is one step smarter and gives the thing to you right from the start.

Eventually, the add-in is here. It’s job is to go to .RC file and increment file version each time you build the binary. It reports the action into build output window:

To install the add-in:

• download and register (regsvr32, administrator) the VisualStudioBuildIncrementerAddIn.dll
• apply one or more Visual Studio integration registry files:
  • Visual Studio 2008 Registration.reg
  • Visual Studio 2010 Registration.reg

Or, alternatively, use installation file VisualStudioBuildIncrementerAddInSetup.msi (version 1.0.4, 379K) to have it done for you in a user-friendly way. Partial source code, a Visual Studio 2010 projectis also there in repository.

Before attributed ATL was deprecated, it was a convenient way to access databases using attributed classes on top of OLEDB Consumer Templates. Does not it look nice?

[
    db_command("SELECT ServerData FROM Server WHERE Server = ?")
]
class CGetServerData
{
public:
    [ db_param(1) ] LONG m_nServer;
    [ db_column(1, length = "m_nDataLength") ] ISequentialStream* m_pDataStream; DBLENGTH m_nDataLength;
};

It worked great with Visual Studio .NET 2003 and it failed to work with later releases. There are questions on internet about the problem, but there few answers if any. As I recently had to convert a project from 2003 version of the compiler to Visual Studio 2008, the problem was finally to be resolved.

The first problem, and an easier one was that you have to put attribute values in quotes. ‘Db_column(1, …’ has to be “db_column(“1″, …’ and besides going through code and making changes, it appeared that if earlier implementation managed to distinguish between ordinal column numbers and field names by checking provided argument to be a number or a string, with Visual Studio 2008 one has to provide strings at any time. If the string is a valid integer, the attribute processor will treat it as an ordinal number.

So if you want your code to be both compiled with 2003 and 2008 versions of Visual Studio, you have a puzzle now: you have to use quotes, but version 2003 will no longer treat the argument as ordinal number. Note that version 2003 will keep compiling the code and the problem will only come up on runtime. As eventually in the project of interest support for version 2003 will be dropped, I was not interested in this problem anymore.

The main problem is related to use of ISequentialStream pointer variable as a data field. Again, it worked great with Visual Studio .NET 2003, it no longer did with Visual Studio .NET 2005. First of all, you cannot use this data type anymore, as templates don’t provide an automatic mapper to OLE DB Type.� Instead of ISequentialStream you have to use IUnknown and QueryInterface the provided pointer before use.

This solves compilation problem, but still the code does not work on runtime. An attempt to bind to the column using such accessor results in DB_E_ERRORSOCCURRED (0x80040E21) “Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done.” A more thorough look gave DBBINDSTATUS_BADBINDINFO (3) for binding to the column of interest.

The cause of the problem is missing DBOBJECT object pointer in the corresponding DBBINDING::pObject field. Why? A general rule for troubleshooting this kind of problem is to enable expanding attributed source code to check what exactly is generated.

The problem is that unlike previous versions of Visual Studio, ATL attributed code provider is no longer generates correct OLEDB template map code for BLOB fields. And this results in incorrectly generated DBBINDING structure, inability to bind to column and as a final result in DB_E_ERRORSOCCURRED error code which does not give a sufficient clue on the root of the problem.

While the map needs a BLOB_* macro for the BLOB column (e.g. BLOB_ENTRY or BLOB_ENTRY_LENGTH), the generated code uses _COLUMN_ENTRY_CODE instead. This causes missing (null) DBBINDING::pObject field in the binding structure:

BEGIN_ACCESSOR_MAP(_CGetServerDataAccessor, 1)
    BEGIN_ACCESSOR(0, true)
        //_COLUMN_ENTRY_CODE(1, DBTYPE_IUNKNOWN, _SIZE_TYPE(m_pDataUnknown), 0, 0, offsetbuf(m_pDataUnknown), offsetbuf(m_nDataLength), 0)
        BLOB_ENTRY_LENGTH(1, __uuidof(ISequentialStream), STGM_READ, m_pDataUnknown, m_nDataLength)
    END_ACCESSOR()
END_ACCESSOR_MAP()

So it appears that to fix the problem, an attributed class needs to be replaced with a non-attributed update. To ease the conversion one can expand attributed source and use it as a base for the non-attributed class.

And example of such correction/replacement is provided below for a reference.

#if TRUE
class _CGetServerDataAccessor
{
public:

DEFINE_COMMAND_EX(_CGetServerDataAccessor, L"SELECT Data FROM Server WHERE Server = ?")

BEGIN_PARAM_MAP(_CGetServerDataAccessor)
    SET_PARAM_TYPE(DBPARAMIO_INPUT)
    //_COLUMN_ENTRY_CODE(1, _OLEDB_TYPE(m_nServer), _SIZE_TYPE(m_nServer), 0, 0, offsetbuf(m_nServer), 0, 0)
    COLUMN_ENTRY(1, m_nServer)
END_PARAM_MAP()

BEGIN_ACCESSOR_MAP(_CGetServerDataAccessor, 1)
    BEGIN_ACCESSOR(0, true)
        //_COLUMN_ENTRY_CODE(1, DBTYPE_IUNKNOWN, _SIZE_TYPE(m_pDataUnknown), 0, 0, offsetbuf(m_pDataUnknown), offsetbuf(m_nDataLength), 0)
        BLOB_ENTRY_LENGTH(1, __uuidof(ISequentialStream), STGM_READ, m_pDataUnknown, m_nDataLength)
    END_ACCESSOR()
END_ACCESSOR_MAP()

public:
    LONG m_nServer;
    IUnknown* m_pDataUnknown;
    DBLENGTH m_nDataLength;
};

class CGetServerData :
    public CCommand<CAccessor<_CGetServerDataAccessor> >
{
public:
// CGetServerData
    HRESULT OpenRowset(const CSession& Session, LPCWSTR pszCommand = NULL) throw()
    {
        if(!pszCommand)
            _V(_CGetServerDataAccessor::GetDefaultCommand(&pszCommand));
        return Open(Session, pszCommand, NULL);
    }
};
#else
[
    db_command("SELECT Data FROM Server WHERE Server = ?")
]
class CGetServerData
{
public:
    [ db_param("1") ] LONG m_nServer;
    [ db_column("1", length = "m_nDataLength") ] IUnknown* m_pDataUnknown; DBLENGTH m_nDataLength;
};
#endif

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.