Error when you click the “File Screens” section of FSRM on Windows Server 2003 R2 with Service Pack 2
When it comes to the cases we work on, issues related to the File Server Resource Manager (FSRM) are few and far between, so it’s a tad unusual that I had the opportunity to work on – and blog about – two of them in little over a month. You can find the first post here. Coincidently, I mentioned that the issue in my previous FSRM post was one of the easier ones to solve. This one’s at the other end of the spectrum. Multiple iterations of the data collection process, escalation services needing to be involved, all in all – a case that - once resolved - leaves you will a good deal of satisfaction!
Opening FSRM and then clicking on “File Screens” under “File Screening Manager” got us the error below. In my experience, this seems to be error that the FSRM console displays when it runs into any error. This means that you may not necessarily be experiencing the issue detailed here.
Looking at the Application Event Log, we found these events:
SRMSVC 12309
Event Type: Error
Event Source: SRMSVC
Event Category: None
Event ID: 12309
Date: 5/18/2011
Time: 7:44:24 PM
User: N/A
Computer: WIN2K3RTR
Description:
A File Server Resource Manager configuration file or import-export file is corrupted. If the corrupt file is a configuration file, it is required that the system or volume be restored from backup. If the file is an import-export file, export the items again and retry the operation without editing the file contents.
Operation:
Enumerating file screen objects on the system.
Context:
Configuration file: \\?\Volume{e47fe6a1-708a-11e0-b513-806e6f6e6963}\System Volume Information\SRM\DataScreenDatabase.xml
Error-specific details:
Error: Invalid version string: 2.0, 0x8004532d, A File Server Resource Manager XML configuration file or import-export file is corrupted.
For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.
Data:
0000: 44 53 43 4e 44 42 53 43 DSCNDBSC
0008: 33 30 31 00 00 00 00 00 301.....
0010: 44 53 43 4e 44 42 53 43 DSCNDBSC
0018: 32 38 33 00 00 00 00 00 283.....
FSRM 0
Event Type: Error
Event Source: FSRM
Event Category: None
Event ID: 0
Date: 5/18/2011
Time: 7:44:24 PM
User: N/A
Computer: WIN2K3RTR
Description:
An unexpected error occurred in the File Server Resource Manager MMC snap-in
at Microsoft.Storage.SrmMmc.FileScreenDataCache.Enumerate(RemoteManager remoteManager, SrmDataCacheEnumEventHandler EventHandler, Int32 BatchSize)
at Microsoft.Storage.SrmMmc.FileScreensDisplayArea.EnumerateItemsIntoListView()
Exception from HRESULT: 0x8004532D
at Microsoft.Storage.ISrmDataScreenManager.EnumDataScreens(String strPath)
at Microsoft.Storage.SrmMmc.FileScreenDataCache.Enumerate(RemoteManager remoteManager, SrmDataCacheEnumEventHandler EventHandler, Int32 BatchSize)
For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.
In hindsight, these events point to the exact issue, but then again, everything is clearer in hindsight!
From the events above, it appears that the we see that 0x8004532D is the common bit of information. Let’s look that up.
C:\Users>err 0x8004532d
# as an HRESULT: Severity: FAILURE (1), Facility: 0x4, Code 0x532d
# for hex 0x532d / decimal 21293 :
SQL_21293_severity_10 sql_err
# Warning: adding updatable subscription for article '%s' may # cause data inconsistency as the source table is already # subscribed to '%s'
# 1 matches found for "0x8004532d"
That doesn’t give us any insight into what the code means, because the only entry returned seems to be from the “sql_err” header file. That sort of leaves us with nothing at all to go on. On to Process Monitor then, and we find that just before the error pops up in FSRM, the DataScreenDatabase.xml file on F: drive is being read.
Looking at the file, there doesn’t appear to be anything wrong (to be called corrupt) with it. Then why is FSRM erroring out?
At this point, a live debug would be a good plan, simply because we need to understand when the error is being set and this isn’t something that you could have FSRM log to a file.
The interesting part is which process you’ve got to attach to, to understand where the error is being set. It seems simple enough that the pop up appears in the FSRM console, which is loaded in mmc.exe, so we’ve got to attach to mmc.exe. But experience will teach you that mmc.exe is just a shell and you need to identify the process/service that is doing the heavy lifting. A quick scan of the Service console – services.msc – gives us a service called “File Server Resource Manager”. This is what we need to attach to. Once this was done, all that remains is to review the source code to understand the code path that leads to the error getting set, identify the condition (if-then-else) that leads to that code path being traversed and set a breakpoint to stop execution at the point the condition check occurs. An examination of the variables being checked revealed that the error gets set when the value is ‘2.0’.
Recall that the events we saw in the Application Event Log also had something to say about ‘2.0’. It was:
Invalid version string: 2.0
This means that when FSRM is parsing the DataScreenDatabase.xml, it runs into 2.0 and throws the error. Since version numbers are generally used to indicate successive generations/iterations of application software, it makes sense to assume that the XML was created somewhere else, like on a Windows Server 2008 system.
A quick check revealed that until recently, these disks were connected to a Windows Server 2008 system. This was downgraded to Windows Server 2003. That’s the cause of the issue. Now the resolution. Shift-Delete all 2.0 DataScreenDatabase.xml files? Yes, and a little bit more.
Having laboriously tested how FSRM deals with a missing DataScreenDatabase.xml file (once you’ve deleted it – as it was an incompatible version), I’ve found that it enumerates all disks that had file screens configured on them/folder under them in this way:
- Check if the System Volume Information folder has an SRM folder.
- Check if a valid DataScreenDatabase.xml file exists in the SRM folder. If yes, repeat step 1 for next disk. If no, proceed to step 3.
- If the file does not exist, create a blank DataScreenDatabase.xml
- Display the error in the FSRM console.
The problem with this approach is that if you delete the DataScreenDatabase.xml file from multiple drives in an effort to resolve the issue, you will need to open the FSRM console, click on “File Screens”, click OK to dismiss the error and then close the FSRM console as many times as you have disks. Once you have done that, and each drive that has a System Volume Information\SRM folder also has a valid DataScreenDatabase.xml file, you'll find that you no longer get the error. You will - nonetheless - need to recreate all "File Screens" manually.
The pecularity of this issue means that there is very little chance that you will ever experience it. But if you do, I hope this post is written well enough to help you resolve the issue - in less time time than it takes to you read it.