Error when you access the “Storage Reports Management” section of FSRM on Windows Server 2003 R2 with Service Pack 2
Some of the previous issues I’ve blogged about require hours upon hours of research to determine the cause of the issue and to fix it. This issue, however, isn’t one of them. All it took to fix the issue here was a good understanding of the Windows Platform and a little intuition.
First, I’ll state the issue. We wanted to set up a couple of Storage Reports for the File Server using File Server Resource Manager (FSRM). To do this, we opened the FSRM console and clicked on the Storage Reports Management (SRM) branch. However, instead of being able to proceed with defining the new reports we wanted to, we got this error:
An unexpected error has occurred. Please check application event log for more information.
Alright, to the Application Event Log then, and this is the event the pop-up was talking about:
Event Type: Error
Event Source: FSRM
Event Category: None
Event ID: 0
Date: 4/11/2011
Time: 2:05:10 PM
User: N/A
Computer: W2K3ROUTER
Description:
An unexpected error occurred in the File Server Resource Manager MMC snap-in
at Microsoft.Storage.SrmMmc.StorageTaskDataCache.Enumerate(RemoteManager remoteManager, SrmDataCacheEnumEventHandler EventHandler, Int32 BatchSize)
at Microsoft.Storage.SrmMmc.StorageTasksDisplayArea.EnumerateItemsIntoListView()
Value does not fall within the expected range.
at Microsoft.Storage.SrmMmc.ISrmReportManager.get_Reports()
at Microsoft.Storage.SrmMmc.ReportTask.EnumReportTasks(RemoteManager remoteManager)
For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.
That points straight to the cause of the issue, doesn’t it! No, well, not really. That’s the stack of the crashing thread that resulted in the pop-up error we saw earlier. What’s a stack, I hear you ask. It’s a data structure that is used to track function calls so that when a functions returns, the system knows which function called the returning function and can continue executing the caller function.
Wait, don’t go away yet! That stack bit was just to tease you, dear reader, and while it helps to know the ins and outs of how software works, just the basics – and the little intuition that I mentioned earlier – should suffice in this case.
Examining the Application Log FSRM error above, we can see that the SRM component was trying to enumerate reports when it encountered the “Value does not fall within the expected range” error. We don’t yet know where the reports are stored.
The perfect tool for when you want to know what registry settings or files are being accessed by a process is Process Monitor.
Download, extract and run procmon.exe and it starts capturing information right away. Run FSRM and click on SRM to reproduce the issue. As soon as you get the pop-up, stop the Process Monitor capture.
Now that we have the Process Monitor log, let’s filter it to remove unnecessary events. But filter it on what? We know that we’re looking for SRM Reports. Trial and error shows that “Path contains SRM Reports” returns no events. Only “Path contains SRM” returns too many events, but “Path contains Reports” returns just 4 events. Perfect, we’re onto something.
At first glance, the events above – though related to SRM – seem to have no real relevance to the issue. There are no ACCESS DENIED events – Process Monitor’s bread and butter – to lead us to the cause of the issue. But this is where Process Monitor’s real power lies. If you look closer, you’ll see that svchost.exe’s search for *.xml files in C:\System Volume Information\SRM\Reports returns just one file – New Text Document.xml
That doesn’t sound right, does it? A New Text Document should have a .TXT extension, not .XML
Things become even more interesting when you navigate to C:\System Volume Information\SRM\Reports and find that New Text Document.xml has a size of 0KB. Hmm, what should we do with this file?
SHIFT+DELETE
Reopen the FSRM console and click the SRM branch. Voila! It works!