在Server 2012方面，我发现没有任何有关此错误的信息。有很多关于Server 2003的错误信息，包括来自Microsoft的更新程序包修补程序以及关于如何解决Server 2008错误的注意事项和2008 R2，但2012年没有。
在安装文件系统资源pipe理器（FSRM）angular色后，Server 2012和Server 2012 R2（版本无关紧要）都会发生错误：
Event ID 8197 Source: SRMSVC File Server Resource Manger Service error: Unexpected error. Error-specific details: Error: GetVolumeNameForVolumeMountPoint, 0x800700001, incorrect function 每次重新启动以及服务重新启动后（特别是启动后30秒），也会发生此错误。 这个错误发生在两台戴尔服务器上：PowerEdge R720和PowerEdge R620。
我发现的第一件事是，这只有在使用UEFI时才会发生 。 服务器使用标准BIOS时没有错误。 我可以停在那里，只是坚持BIOS，但我不想失去任何UEFI和服务器2012年的新function。
最初，我认为这是戴尔的UEFI实施问题，因为它发生在我的新服务器以及在DELL PowerEdge ESX主机上运行的虚拟机上。 但是，我能够在非Dell硬件上运行的另一个虚拟机重现此错误。 这意味着问题是与微软。 在UEFI上的服务器2008 R2上安装FSRM不会产生错误，只有2012和2012 R2会将此缩小到UEFI的Server 2012问题。
除了事件查看器中的明显的红色x之外，我还没有看到任何负面的这个错误。 我完全testing了FSRMfunction，发现一切似乎都顺利运行。 不幸的是，我不是那种只是忽略一个未知的持续性错误的types，所以我花了很多时间去尝试深入了解它。 我高度的动力得到这个想法，因为我曾经在谷歌这一错误和服务器2012提到重启消失卷（我不想在我的道路上popup）。
在戴尔和微软之间来回奔波之后，我收到了有关这个错误的“答案”。 这是微软的回应：
我们的升级工程师debugging了这个问题，发现这是EFI系统上的一个devise行为。 我们已经在硬件机器和虚拟机上复制了这个问题。
我们想解释一下，我们可以放心地忽略这个事件。 当FSRM服务检查系统分区时，会出现错误消息。 在EFI系统上，EFI系统分区是一个FAT系统，在调用GetVolumeNameForVolumeMountPoint（）函数时会失败。 这是正常的，FSRM服务期望在EFI系统的内部代码中这将失败。 该错误消息只是logging信息的目的，这种情况，这就是为什么你可以放心地忽略它。
就我个人而言，我认为这是一个远离的回应。 我回过头来提醒他们，这不会发生在UEFI上的Server 2008 R2，所以如果这是真正的“由devise”由于EFI分区的格式化服务器2008 R2也将有相同的错误…
如果我碰巧听到相关的回应，我会更新。 现在我只想把这个信息拿出来，以防万一我不是唯一见过这个问题的人：}