Windows 8 如何模拟Microsoft Surface拆卸超时？

我一直在为Windows 8开发一个应用程序，可以从Visual Studio 2012测试挂起、恢复、关闭等。然而，当我在Microsoft Surface上测试应用程序时，还有一种状态我似乎无法模拟

当一个应用程序打开，你让它的表面保持一段时间不变时，屏幕会变暗，然后最终关闭。如果我等待足够长的时间，可能是1或2分钟，然后点击开始按钮，它会将我带到锁屏，在那里我可以登录。一旦我登录，它将显示我的应用程序，我把它放在哪里了。但是，1秒钟后，它立即崩溃，曲面将我带回开始屏幕

我无法使用VisualStudio和模拟器来模拟这一点。使用调试位置挂起/恢复不会重新创建此操作

我查看了表面上的事件日志，发现我的应用程序因以下原因崩溃：

The process was terminated due to an unhandled exception. 

Exception Info: System.Exception Stack: at
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at
System.Threading.WinRTSynchronizationContext+Invoker.<InvokeCore>b__0(System.Object) at
System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object) at
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at
System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() at System.Threading.ThreadPoolWorkQueue.Dispatch() at
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

由于未处理的异常，进程已终止。
异常信息：系统。异常堆栈：位于
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw（）位于
位于的System.Threading.WinRTSynchronizationContext+Invoker.b__0（System.Object）
位于的System.Threading.QueueUserWorkItemCallback.WaitCallback_上下文（System.Object）
位于的System.Threading.ExecutionContext.RunInternal（System.Threading.ExecutionContext，System.Threading.ContextCallback，System.Object，Boolean）
运行（System.Threading.ExecutionContext，System.Threading.ContextCallback，System.Object，Boolean）
System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem（）位于System.Threading.ThreadPoolWorkQueue.Dispatch（）位于
System.Threading.\u ThreadPoolWaitCallback.PerformWaitCallback（）

我不知道怎么找到这个。我用一个标准的消息框处理所有未处理的异常，但它没有显示出来。我们一直非常擅长避免“异步无效”，并确保所有内容都有“异步任务”并正确等待。所以，我有点卡住了。我找不到发生这种事的地方

---

有人知道我如何模拟这个，或者至少让事件日志更详细吗？

在我看来，您拥有测试场景所需的一切。但您可能不知道，您可以像在本地运行一样，在表面上远程调试应用程序。因此，您可以继续处理您的用例，并让Visual Studio捕获异常：

这很容易。这里有一个演练：

好的，我想出来了

MediaElement

控件和音量存在问题。当应用程序被重新激活时，正如我上面所解释的，我们会收到通知，该卷已更改。但出于某种原因，如果我们试图在应用程序重新激活时操纵

MediaElement.Volume

，它会抛出一个异常。这个异常没有消息，只是一些奇怪的十六进制数

这只发生在平板电脑上，很难检测到。基本上，对于所有播放媒体文件的人来说，您应该像这样尝试/捕捉它：

try
{
   myMediaElement.Volume = .3;
}
catch (Exception ex)
{
   // I don't really know what to do here.
   // but at least my app doesn't crash anymore :)
}

---

无论如何，谢谢你们杰瑞尼克松和丘克斯的帮助

我没有答案，但我会在加载/保存和导航方法中添加一些日志记录。我假设您使用的是LayoutWarePage作为基础-如果是这样，您可以覆盖

LoadState

、

SaveState

、

OnNavigatedTo

和

OnNavigatedFrom

。日志至少会让你了解崩溃前你的应用程序中发生了什么。谢谢@chuex。我尝试了页面事件/状态中的所有内容，但没有成功。这是框架中的深层内容。我相信，一旦我弄明白了这一点，我会学到一些有价值的东西：）你是否碰巧在你的应用程序中使用了任何计时器，比如

dispatchermer

？当我的应用程序不在屏幕上时，计时器将暂停，然后当我切换回我的应用程序时，计时器将立即启动。只需查看其他内容。谢谢@Jerry，但不幸的是，远程调试并没有模拟这种情况。当表面变暗并关闭屏幕时，一段时间后，VisualStudio会告诉我它已失去与远程设备的连接，调试停止。我使用暴力调试，移除所有东西，然后慢慢地重新引入片段，直到找到罪魁祸首。我明白了。很抱歉发生了这种事。日志里什么都没有？那么，你需要在你的头脑中进行一步一步的思考。恢复发生时激发的内容。我无法真正帮助您了解细节，但您可以将其写入文件（如本地文件夹）并进行类似的调试。这几乎肯定是在你的恢复，激活或加载或类似的方法。再说一次，它可能与序列化有关。也许再多做几次

尝试{}catch{}

可以帮助您识别它。如果你想的话（当然是为了测试），可以尝试包装整页。奇怪的十六进制数是多少？我的猜测是这是一个HRESULT，它将提供关于可能发生的情况的进一步线索。@RaymondChen，“来自HRESULT的异常：0xC00D4E86”快速显示错误代码意味着“音频播放设备不再存在”。可能发生的情况是音频设备由于断电而脱机，因此当你的应用程序恢复时，它需要重新获得它。