Alois Kraus

blog

  Home  |   Contact  |   Syndication    |   Login
  114 Posts | 8 Stories | 297 Comments | 162 Trackbacks

News



Article Categories

Archives

Post Categories

Image Galleries

Programming

Whenever I do use Visual Studio and try to compile something under 64 bit I run into problems. It seems that most MS Devs for Visual Studio and the relevant tool chain are still mainly writing 32 bit applications.

Here are some of the latest issues I did run into.

 

COM applications targeting x64 are still using x32 as target platform for the MIDL compiler by default

Resolution: You have to select in the UI MIDL – Target Environment X64 by yourself. Alternatively you can edit the vcxproj file directly and set the flag there:

  <Midl>
  <TargetEnvironment>X64</TargetEnvironment>

 

The othere issue was that on my dev machine Visual Studio 2010 SP1 did freeze quite often. The dump showed that it did hang while loading  the assembly Microsoft.VSDesigner. I have filed a Connect issue for this but I got not any helpful feedback yet. In the meantime I did find out by myself why VS was hanging. Once the hang did occur it was freezing quite often which is good for a repro but very annoying if there is nothing you can do about it. I did send my error reports to MS every time hoping that they resolve the issue before VS2012 is released. The Connect support person requested another dump from me this time taken with VS directly. I have to remember that for my own trouble shooting that VS can now also take dumps which really helps. The interesting thing was that the VS call stack was more helpful since it seemed to resolve the symbols better. The deadlock has frozen the UI thread while some stack frames from MSI were on it.

 

    ntdll.dll!_ZwWaitForSingleObject@12() + 0x15 bytes   
    ntdll.dll!_ZwWaitForSingleObject@12() + 0x15 bytes   
    kernel32.dll!_WaitForSingleObjectExImplementation@12() + 0x43 bytes   
    msenv.dll!_VsCoCreateAggregatedManagedObject() + 0xe2 bytes   
    msenv.dll!_VsLoaderCoCreateInstanceUnknown() + 0x8e bytes   
    msenv.dll!CVsLocalRegistry4::CreateInstance() + 0x4a bytes   
    msenv.dll!CXMLMemberIndexService::GetCulture() + 0x17f5 bytes   
    msenv.dll!CXMLMemberIndexService::LocateAndOpenXMLFile() + 0x14 bytes   
    msenv.dll!CXMLMemberIndexService::CreateXMLMemberIndex() + 0x78 bytes   
    cslangsvc.dll!CMetaDataLoader::EnqueueMemberIndexRequest() + 0xe80cc bytes   
    cslangsvc.dll!CMetaDataTypeData::GetDocumentationComment() + 0x1b bytes   
    cslangsvc.dll!CSymbolDescription::CPartCollector::ConditionallyAddDocCommentParts<CTypeData>() + 0x32 bytes   
    cslangsvc.dll!CSymbolDescription::CTypeProviderHelper::TryExecute() + 0x278 bytes   
    cslangsvc.dll!CSymbolDescription::CNameProviderVisitor::Visit() + 0x56 bytes   
    cslangsvc.dll!CTypeProvider::Accept() + 0x13 bytes   
    cslangsvc.dll!CSymbolDescription::CNameProviderVisitor::TryExecute() + 0x2a bytes   
    cslangsvc.dll!CSymbolDescription::TryGetDescription() + 0x37 bytes   
    cslangsvc.dll!CSymbolDescription::TryAppendDescription() + 0x61 bytes   
    cslangsvc.dll!CSpanBinder::TryExecuteAndGetDescription() + 0x88 bytes   
    cslangsvc.dll!CQuickInfo::TryGetRawIntelliSenseQuickInfo() + 0x81 bytes   
    cslangsvc.dll!CQuickInfo::TryGetFullIntelliSenseQuickInfo() + 0x4d bytes   
    cslangsvc.dll!CQuickInfo::TryExecute() + 0x3e bytes   
    cslangsvc.dll!CEditFilter::GetDataTipText() + 0xdd bytes   
    cslangsvc.dll!CVsEditFilter::GetDataTipText() + 0x52 bytes   
    user32.dll!_InternalCallWinProc@20() + 0x23 bytes   
    user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes   
    user32.dll!_DispatchMessageWorker@8() + 0xed bytes   
    user32.dll!_DispatchMessageW@4() + 0xf bytes   
    msi.dll!MsiUIMessageContext::RunInstall() + 0x21231 bytes   
    msi.dll!RunEngine() + 0xb3 bytes   
    msi.dll!ConfigureOrReinstallFeatureOrProduct() + 0xfa bytes   
    msi.dll!_MsiReinstallFeatureW@12() + 0x66 bytes   
    msi.dll!ProvideComponent() + 0x10957 bytes   
    msi.dll!ProvideComponentFromDescriptor() + 0x154 bytes   
    msi.dll!_MsiProvideAssemblyW@24() + 0x437 bytes   
    msenv.dll!_VsCoCreateAggregatedManagedObject() + 0xe2 bytes
   
    msenv.dll!_VsLoaderCoCreateInstanceUnknown() + 0x8e bytes   
    msenv.dll!CVsLocalRegistry4::CreateInstance() + 0x4a bytes   
    msenv.dll!CXMLMemberIndexService::GetCulture() + 0x17f5 bytes   
    msenv.dll!CXMLMemberIndexService::LocateAndOpenXMLFile() + 0x14 bytes   
    msenv.dll!CXMLMemberIndexService::CreateXMLMemberIndex() + 0x78 bytes   
    cslangsvc.dll!CMetaDataLoader::EnqueueMemberIndexRequest() + 0xe80cc bytes   
    cslangsvc.dll!CMDMemberData::GetDocumentationComment() + 0x51 bytes   
    cslangsvc.dll!CSymbolDescription::CPartCollector::ConditionallyAddDocCommentParts<CMemberData>() + 0x2f bytes   
    cslangsvc.dll!CSymbolDescription::CMemberProviderHelper::TryExecute() + 0xdc bytes   
    cslangsvc.dll!CSymbolDescription::CNameProviderVisitor::Visit() + 0x53 bytes   
    cslangsvc.dll!CAbstractNameProviderBoolDefaultVisitor::Visit() + 0x2b bytes   
    cslangsvc.dll!CAggregateMemberProvider::Accept() + 0x16 bytes   
    cslangsvc.dll!CSymbolDescription::CNameProviderVisitor::TryExecute() + 0x2a bytes   
    cslangsvc.dll!CSymbolDescription::TryGetDescription() + 0x37 bytes   
    cslangsvc.dll!CSymbolDescription::TryAppendDescription() + 0x61 bytes   
    cslangsvc.dll!CSpanBinder::TryExecuteAndGetDescription() + 0x88 bytes   
    cslangsvc.dll!CQuickInfo::TryGetRawIntelliSenseQuickInfo() + 0x81 bytes   
    cslangsvc.dll!CQuickInfo::TryGetFullIntelliSenseQuickInfo() + 0x4d bytes   
    cslangsvc.dll!CQuickInfo::TryExecute() + 0x3e bytes   
    cslangsvc.dll!CEditFilter::GetDataTipText() + 0xdd bytes   
    cslangsvc.dll!CVsEditFilter::GetDataTipText() + 0x52 bytes   

The language service tries to get some tool tip (GetDataTipText) text and tries to load an assembly. For reasons unknown to me MSI is used to get an assembly and install it if it is not already present. Since the requested assembly was not found an installation was performed. While the installation is running MSI does pump again window messages which does let VS again to call GetDataTipText since my mouse was still hovering over some code element in the editor. MSI would be called again to resolve the same assembly but since the installation is already running VS does block. There is another helper thread running at cslangsvc.dll!CBackgroundQueue::ExecuteRequests() which seems wait for the msi installation to finish on the UI thread but since MSI cannot report any progress or failure back via the Window message loop we have a classic hang. You could ask how I do know about the other thread holding the same lock?

Starting with Windows Vista WCT (Wait Chain Traversal) was added to the Kernel which is accessible via some Windbg extensions or much easier via the Windows Resource Monitor (at the comamnd line enter: perfmon.exe /res). Hung processes are marked as red and are displayed at first in the process list (very nice). From there it is a simple right click on the hung process to analyze the locks. There you can see directly which thread is waiting for which other thread/s. No more kernel debugging!

The question that remains is why the MSI installation did never complete anyway which would have caused only one VS hang. To see what is going on on the MSI side you need to enable MSI logging. With a little practice you can quickly find the interesting lines:

=== Verbose logging started: 05.12.2011 15:57:51 Build type: SHIP UNICODE 5.00.7600.00 Calling process: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe ===
Command Line: REINSTALL=SysClrTypFeature REINSTALLMODE=pocmus CURRENTDIRECTORY=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE CLIENTUILEVEL=3 CLIENTPROCESSID=11280
MSI (s) (5C:38) [06:29:54:573]: SOURCEMGMT: Failed to resolve source
MSI (s) (5C:38) [06:29:54:573]: Product: Microsoft SQL Server System CLR Types (x64) -- Error 1706. An installation package for the product Microsoft SQL Server System CLR Types (x64) cannot be found. Try the installation again using a valid copy of the installation package 'SQLSysClrTypes_amd64_enu.msi'.

The MSI which was tried to patch was Microsoft SQL Server System CLR Types (x64). For some reason the original MSI was no longer cached in the \Windows\Installer directory which caused the installation silently to fail. From there it is easy to resolve the issue: Install the original Microsoft SQL Server System CLR Types (x64) MSI and you should see no more failed patching while VS is running.

This issue was really annoying but since then VS 2010 is running happily on my machine without any hangs. I am really happy that I was able to resolve this problem so easily. The only issue I still do have that VS2010 is a memory hog and I do pity the poor people with slow hard discs. On these machines VS 2010 is no fun to use.

posted on Friday, December 9, 2011 10:53 AM