我们在生产站点上有一台服务器，它运行24/7，尽pipe它的大部分stream量是正常营业时间。 其function是使用基于Dialogic的硬件运行电话呼叫中心。
机器的本地用户发现机器在今天早上8点半左右对客户端应用程序没有反应，当我们尝试远程访问时，我们可以ping通它，但无法获得RDP远程访问。
大约在9.15时，我们要求他们从机器上拔下电源线并重新启动，当它恢复运行时，我们可以继续工作。
我们发现RAID正在做一个validation和重build（我认为这是因为不正常关机）。
一旦我们能够在确保实时服务再次运行（在那里没有问题）之后能够查看服务器，我们就检查了事件日志。
我可以看到的最后一个“正常”事件条目是一些自动化的过程，它具有身份validation失败（LsaSrv，SPNEGO（谈判者）事件ID 40960，1:19:26，然后是2:49:27，下一个事件当我们冷启动机器时，日志是9:15，那个事件日志条目说：
事件ID 6008 2011年5月10日2:49:40之前的系统closures是意外的。
接下来从那个入口有正常的启动条目，因为各种服务出现，机器已经罚款。
我们已经运行了蓝屏查看器，并确认没有可能导致蓝屏的蓝屏。 机器不能在机架上访问KVM，所以没有人能够在重新启动之前看到屏幕上有什么。
问题：1.这些身份validation失败有很多，我要求本地pipe理员解决问题（停止或修复身份validation） – 是否可以build立并导致这个问题？
任何想法实际上发生了什么？
我可以采取哪些措施来尝试识别？ 它可能是硬件？ 这是相当新的，最多几十年，质量好的工具包，这是我们两年来的第一个问题。
Windows如何确定上次意外关机的date/时间？ 它是基于最后一个日志条目吗？ 还是它保持时间的运行观察，然后如果这是设置，当它重新启动它知道什么时候失败？
难道这台机器的高层function简直就冻结了，只剩下低级ping这样的基本function还在工作吗？ 如果是这样，那告诉我什么？
底线是我正在被pipe理层问简单的问题，发生了什么，我们如何确保它不会再发生，因为我相信你可以想象:)
非常感谢，让我知道如果我可以提供更多的背景或检查服务器上的任何东西。
马特。
事实上，你有6个小时的死亡时间没有事件让我觉得这是硬件。 Raid重build可能是由电源插拔引起的，也可能是罪魁祸首。
这些事件，他们是应用程序日志，系统日志还是两者？
有很多的可能性来告诉你事实，但是，我会开始在KVM上获得这个服务器，以便本地pipe理员可以看到发生了什么，如果它再次发生，我说如果因为它可能是像电源一样简单波动，并可能永远不会再发生。 我假设服务器在UPS上，但是最后一次testing的时间是什么时候？