我有一个托pipe的VPS（Windows Server 2012），并在pipe理程序中将其closures会在Windows日志的系统视图中导致以下严重事件：
> Log Name: System Source: Microsoft-Windows-Kernel-Power Date: > 4/13/2015 12:05:28 PM Event ID: 41 Task Category: (63) Level: Critical > Keywords: (2) User: SYSTEM Computer: ********** Description: The > system has rebooted without cleanly shutting down first. This error > could be caused if the system stopped responding, crashed, or lost > power unexpectedly. Event Xml: <Event > xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> > <System> <Provider Name="Microsoft-Windows-Kernel-Power" > Guid="{331C3B3A-2005-44C2-AC5E-77220C37D6B4}" /> <EventID>41</EventID> > <Version>3</Version> <Level>1</Level> <Task>63</Task> > <Opcode>0</Opcode> <Keywords>0x8000000000000002</Keywords> > <TimeCreated SystemTime="2015-04-13T10:05:28.557824700Z" /> > <EventRecordID>594549</EventRecordID> <Correlation /> <Execution > ProcessID="4" ThreadID="8" /> <Channel>System</Channel> > <Computer>**********</Computer> <Security UserID="S-1-5-18" /> > </System> <EventData> <Data Name="BugcheckCode">239</Data> <Data > Name="BugcheckParameter1">0xfffffa8007110700</Data> <Data > Name="BugcheckParameter2">0x0</Data> <Data > Name="BugcheckParameter3">0x0</Data> <Data > Name="BugcheckParameter4">0x0</Data> <Data > Name="SleepInProgress">0</Data> <Data > Name="PowerButtonTimestamp">0</Data> <Data > Name="BootAppStatus">0</Data> </EventData> </Event> 有关于事件（41）的信息在这里： https : //support.microsoft.com/en-us/kb/2028504#method1
有关错误检查的信息（239 = 0xEF）： https ：//msdn.microsoft.com/en-us/library/windows/hardware/ff560358( v =vs.85).aspx
这个事件是由我的VPS连接到第二个以太网networking触发的。
我已经向主办方报告了这一点，他们向我保证：
“当VPS在pipe理程序中closures时，这是正常事件”
他们是一个非常可靠的提供者，所以我倾向于相信他们，但是也不完全确定。 所以我的问题是：在这种情况下这个事件是令人担忧的还是正常的？
—从主机（transip.nl）更新
“系统已经重新启动，而没有首先closures，如果系统停止响应，崩溃或意外解决电源，可能会导致此错误。 是合乎逻辑的
由于我们无法访问操作系统本身，因此无法从那里执行重新引导，因此我们通过closures虚拟机pipe理程序中的VPS来做到这一点，确实会产生这样的报告。
在坚持自由主义之后：
那么，我真的不能给你另一个答案。 当您将VPS添加到专用networking或将其删除时，或者通过控制台重新启动时，这绝不会产生“干净closures”。
如果我们这样做的话，那么在内核出现紧急情况或操作系统中存在其他严重问题的情况下，就不能重新启动，因为它不会响应这个命令。
更新 共享ACPI选项后：
如果不是因为这需要在操作系统中运行一个守护进程，ACPI确实是一种可能性，因此客户总是可以selectclosures它。 此外，在内核恐慌/蓝屏死机的情况下，这将不起作用，因为OS中的守护进程也被阻塞。
它不会给我们任何保证，关机/重新启动实际上执行，这将使“重置”选项相当不可靠。
显然这不好。 为什么会这样？ 这是一个BSOD。 你不会杀死Linux上的init进程，那么为什么在Windows上这样做呢？
更新
显然，他们不支持通过ACPI关机（这不是很酷），而只是“杀死电源”。 您应该鼓励他们实施ACPI电源button解决scheme。 这就是VirtualBox所做的，它可以很好地运行，可能每个操作系统都在运行。
但是，这仍然不能解释为什么你会得到蓝屏。
同时，您应该通过RDPclosures您的VPS以避免数据损坏。