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.
||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.