Your SQL Server Setup may hang forever when it’s almost at the 99 %!

Consider this scenario, I rebooted several times, disabling my favourite antivirus and still unable to get a clue from all the logs possible. I start looking at my favourite blogs and here I am.
Check out if your symptoms match the following.
I am installing SQL Server including reporting services and my setup is getting hung forever almost at the end when it tries to configure reporting services”.

Some environment details can give you more relief
SQL Server: SQL Server 2008 R2 Standard Edition
Machine processor count: 2
OS version: Windows XP
OS service pack: Service Pack 3
OS region: United States
OS language: English (United States)
OS architecture: x86
Process architecture: 32 Bit
OS clustered: No

Note: This behaviour was reported while installing SQL Server 2008 R2 on Windows XP. We haven’t seen this behaviour on other versions of the operating system at the time we drafted this.

Our regular troubleshooting routine is to look into the Detail.txt file, just to find out if there is some smoke there. I see below lines in the Log.


2011-10-13 14:20:17 Slp: Running Action: SqlRSConfigAction_install_ConfigRC_Cpu32

2011-10-13 14:20:17 Slp: Action Data:

2011-10-13 14:20:17 Slp: Feature = RS_Server_Adv_sql_rs_Cpu32

2011-10-13 14:20:17 Slp: Scenario = install

2011-10-13 14:20:17 Slp: Timing = ConfigRC

2011-10-13 14:20:17 Slp: ConfigObjectType = Microsoft.SqlServer.Configuration.RSExtension.SQLRSConfigurationPrivate

2011-10-13 14:20:17 Slp: FeatureName = RS_Server_Adv

2011-10-13 14:20:17 Slp: FeatureCpuType = Cpu32

2011-10-13 14:20:17 Slp: FeaturePackageId = sql_rs

2011-10-13 14:20:17 RS: STATUS: Install_ConfigRC started



2011-10-13 14:20:19 RS: Install perf counters started.



2011-10-13 14:20:19 Slp: Sco: Attempting to replace property in string

2011-10-13 14:20:19 Slp: Sco: Attempting to replace property in string

2011-10-13 14:20:19 Slp: Sco: Attempting to replace property in string

2011-10-13 14:20:19 Slp: PerfCounter calling lodctr: 'C:\Program Files\Microsoft SQL Server\MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer\bin\perf-ReportServerrsperfctr.ini'

2011-10-13 14:20:20 RS: Installing web service managed performance counters.


This kinda gives me a clue that there is something smelly with the performance counter. A quick glance in to the application event log would give and interesting find.


Performance counters for the ReportServer (SQL Server Reporting Services (MSSQLSERVER)) service were loaded successfully. The Record Data contains the new index values assigned to this service.

My previous hypothesis suspecting the performance counters does not seem valid at this point. A further peek into the sql_rs_Cpu32_1.log file would give you the below confirmation.


MSI (s) (34:24) [14:20:02:494]: Product: SQL Server 2008 R2 Reporting Services -- Installation completed successfully.

MSI (s) (34:24) [14:20:02:494]: Windows Installer installed the product. Product Name: SQL Server 2008 R2 Reporting Services. Product Version: 10.50.1600.1. Product Language: 1033. Installation success or error status: 0.


As an optimist I toiled rebuilding the performance counter for reporting services once again hoping this might help me moving the setup forward but no luck.


Clueless J, elevating the level of troubleshooting seems to be the only way.


Note: You may want to try this but I would suggest you download the latest Debugger and the public symbols.

I would suggest involving Microsoft Support at this point if you are not familiar with the Debugger commands.

Command: adplus.exe -hang -p <PID> -o c:\dumps

PID is the process identifier for setup100

This command should be exercised while the setup is hung and the generous debugger would generate the hang dump for us.



Dump Analysis.

A quick review of the threads in the dump we should be able to identify the one performing activity related to perfmon counters.

Remember the last line in the setup logs:

2011-10-13 14:20:20 RS: Installing web service managed performance counters.


 0:000> kL 100

 ChildEBP RetAddr

 0013d75c 77e7c672 ntdll!ZwRequestWaitReplyPort+0xc

 0013d7a8 77e7a80e rpcrt4!LRPC_CCALL::SendReceive+0x228

 0013d7b4 77e7a83f rpcrt4!I_RpcSendReceive+0x24

 0013d7c8 77ef5675 rpcrt4!NdrSendReceive+0x2b

 0013dbac 666b1e64 rpcrt4!NdrClientCall2+0x222

 0013dbc0 666b21ff infoadmn!R_InitW3CounterStructure+0x1b

 0013dbfc 5aaf10b5 infoadmn!InitW3CounterStructure+0x1b

 0013dc14 77e42468 w3ctrs!OpenW3PerformanceData+0x43

 0013e304 77e41144 advapi32!OpenExtObjectLibrary+0x58f

 0013e478 77e09f09 advapi32!QueryExtensibleData+0x3d8

 0013e850 77df239a advapi32!PerfRegQueryValue+0x513

 0013e940 77dd708b advapi32!LocalBaseRegQueryValue+0x306

 0013e978 0092ac1e advapi32!RegQueryValueExW+0xa2

 0013e9b4 79a10a96 CLRStub[StubLinkStub]@92ac1e

 0013ea24 7927fea1 mscorlib_ni!Microsoft.Win32.RegistryKey.InternalGetValue(System.String, System.Object, Boolean, Boolean)+0x71e716

 0013ea40 7a9f9969 mscorlib_ni!Microsoft.Win32.RegistryKey.GetValue(System.String)+0x21

 0013ea7c 7a9f71b4 System_ni!System.Diagnostics.PerformanceMonitor.GetData(System.String)+0x6d

 0013eab0 7a9f7398 System_ni!System.Diagnostics.PerformanceCounterLib.GetPerformanceData(System.String)+0xa0

 0013eb0c 7a9f850a System_ni!System.Diagnostics.PerformanceCounterLib.get_CategoryTable()+0x5c

 0013eb20 7a9ebf2c System_ni!System.Diagnostics.PerformanceCounterLib.CategoryExists(System.String, System.String)+0x46

 0013eb58 09287a49 System_ni!System.Diagnostics.PerformanceCounterCategory.Create(System.String, System.String, System.Diagnostics.PerformanceCounterCategoryType, System.Diagnostics.CounterCreationDataCollection)+0xb4

 0013eb70 0928795f Microsoft_SqlServer_Configuration_RSExtension!Microsoft.ReportingServices.Common.RSPerfCounterInstallUtil.InstallWebServicePerfCounters(Boolean)+0x31


The top three lines of the thread stack suggest an inter process communication and the current thread waiting for a response from the remote host/process. And it cannot progress until the response is received. Our next task would be to understand the type of communications involved as well as the processes involved;


Let’s take a look at the following frames of the thread stack:


0013dbfc 5aaf10b5 infoadmn!InitW3CounterStructure+0x1b

0013dc14 77e42468 w3ctrs!OpenW3PerformanceData+0x43

0013e304 77e41144 advapi32!OpenExtObjectLibrary+0x58f


Any application that supports performance counters must have a performance subkey under the services subkey ,


Which exposes the open, collect and close methods a client can call to retrieve the counter information and the values for these counters. It also contains the dll name that exposes these functions. Any Performance monitoring Client can use these procedures to monitor the performance of the application/service.


More information:


In our case the above the three frames mentioned above suggest that the setup (Client in this communication) is trying to retrieve the information about the performance counters registered by IIS. And hence calls the Open function exposed by dll w3ctrs and waits for a response from the IIS server.

As mentioned earlier you could also find this information for IIS service under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W3SVC\Performance

Which points to OpenW3PerformanceData and w3ctrs.dll


At this stage here are the options we would try:

· Make sure that the dlls w3ctrs and infoadmn involved are up to date and match with the service pack on the IIS and Operating System. If they match we should not notice this problem. If they don’t re-install the patches required to update the dlls and rerun the setup.

· Though option 1 seems to be the ideal approach, we could workaround this behaviour by Stopping the IIS Service and rerunning the Setup.


In our scenario, stopping the IIS service and restarting the setup did the trick!!!

Written by:
Manish Upadhyay

Support Engineer, Microsoft SQL Server Support


Reviewed By:
Kartik Attuluri, Technical Lead, Microsoft SQL Server Support
Levi Justus, Technical Lead, Microsoft SQL Server Support