SQL Server Reporting Services 2017 Instability / Janky product?

Question

SQL Server Reporting Services 2017 Instability / Janky product?

johnzabroski

SSCrazy

Points: 2355
More actions
March 8, 2019 at 8:52 am

#381753

Hi,
We upgraded to SQL Server 2017 on January 4th this year, and we've had several situations where SQL Server Reporting Services (SSRS) just... stops working. The website starts returning 503 Service Unavailable errors.
When I look in the logs, I see that I frequently get the following "funny/sad" log message, where the logging system logs that it cannot delete log files:
Exception deleting expired log fileSystem.IO.IOException: The process cannot access the file 'C:\Program Files\Microsoft SQL Server Reporting Services\SSRS\LogFiles\ReportingServicesWMI_2019_01_06_14_36_50.log' because it is being used by another process.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.File.InternalDelete(String path, Boolean checkHost)
   at Microsoft.BIServer.HostingEnvironment.Logger.DeleteExpiredFiles(String traceFolder, Int32 keepUntilDays)
I know a lot of people have not moved to SSRS 2017 yet due to the fact they removed the ability to host multiple instances of reporting services on the same machine, but is anyone else running into this issue?
Somewhat unrelated, SSRS 2017 just feels very janky and unstable. I pointed out to a Microsoft employee that the SSRS 2017 standalone installer installs a version of SSRS with the phrases "RC" and "CTP2" in window title bars. You can see my attached screenshots in case you're unfamiliar.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Andrew P SSCarpal Tunnel Points: 4649 More actions · Answer 1

Hi johnzabroski,

Somewhat sadly, I haven't had the same experience with our SSRS 2017 installation. Our production SSRS instance is pretty busy and has remained steady for over a year. We'd notice it dying, and see the log entries, but we haven't seen either.

Here's a screenshot of our Reporting Services Configuration Manager, which doesn't include the CTP/RC text on your install, even though I think we're on the same SQLServerReportingServices.exe installer version.The C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\RSConfigTool.exe (SSRS configuration manager executable) file version is 14.0.1000.169, in-case this helps.

I suspect you may have antivirus or some other real-time scanning tools locking the log files while reading them, causing SSRS to crash. Is it possible to run Process Monitor on the server to monitor file access activity on those log files? Alternatively, you may be able to see what's reading/locking those files using LockHunter immediately after an incident.

Best,
Andrew

johnzabroski SSCrazy Points: 2355 More actions · Answer 2

Here's a screenshot of our Reporting Services Configuration Manager, which doesn't include the CTP/RC text on your install, even though I think we're on the same SQLServerReportingServices.exe installer version.The C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\RSConfigTool.exe (SSRS configuration manager executable) file version is 14.0.1000.169, in-case this helps.

Thanks, that's helpful. Our RSConfigTool.exe was 14.0.800.90. https://buildnumbers.wordpress.com/sqlserver/ doesn't keep track of SSRS, so it's tough to make sense of what's installed. 10.0.800.90 matches up exactly with SQL Server 2017 RC1, but SSRS releases don't necessarily sync up to SQL Server releases.

14.0.800.90

SQL Server 2017 (vNext) RC1 (Release Candidate 1)

2017 July 17

I swear to God I installed this correctly using the steps below. The only "unknown" is that our SQL Server 2017 installation media was provided by Amazon Web Services, so it's possible the installation media was bad? But our version of SQL Server 2017 is exactly correct - December 2018 release for a Jan 4 2019 install.

Microsoft released a new version of SSRS on February 12, 2019. I went through the same process as before, which has given me a new SqlServerReportingServerInstaller.exe:

1. Open SQL Server 2017 Installation Center 64-bit
2. Click the Installation tab
3. Click Install SQL Server Reporting Services
4. This will open the following URL in Internet Explorer: https://www.microsoft.com/en-us/download/details.aspx?id=55252

The new installer version is 14.0.6981.38291. I'll install this and see how it goes.

I'm completely stumped as to how I got such an old version. Even using The Internet Wayback Machine at archive.org, the August 2018 snapshot says 14.0.600.744 , released 4/26/2018. One possibility is Microsoft had this download mirrored, and one of the mirrors never updated its cache? That just seems crazy, but crazy does happen in computer systems heavily reliant on caching!

I suspect you may have antivirus or some other real-time scanning tools locking the log files while reading them, causing SSRS to crash. Is it possible to run Process Monitor on the server to monitor file access activity on those log files? Alternatively, you may be able to see what's reading/locking those files using LockHunter immediately after an incident.

Thanks, I tried LockHunter, and the offending program is WmiPrvSE.exe. I found a StackOverflow answer explaining how to tell which "wmi provider", hosted by WmiPrvSE.exe, has this file open. Given this behavior happens on every boot, I can probably try this and wait until the next reboot in April.

johnzabroski SSCrazy Points: 2355 More actions · Answer 3

The issue with the wrong version of SSRS being installed (CTP 1 RC1) has come back again.

I'm really perplexed as to what is going on.

I fixed this on 3/11/2019.

Sue_H SSC Guru Points: 90860 More actions · Answer 4

Did you ever install an RC or CTP version of 2017 on this server?

Also, you may want to go through the installation logs in the setup bootstrap\log directory.

Sue