C# WPF应用程序的硬件加速问题-分析崩溃转储

C# WPF应用程序的硬件加速问题-分析崩溃转储,c#,wpf,windbg,crash-dumps,C#,Wpf,Windbg,Crash Dumps,我有一个WPF应用程序在客户端计算机上崩溃。我的初步分析表明,这是因为H/W加速,在注册表级别禁用H/W加速可以解决这个问题。现在我必须确定这是由H/W加速度引起的。我有可用的崩溃转储,有堆栈跟踪 9c52b020 80636ac7 9c52b0bc e1174818 9c52b0c0 nt!_SEH_prolog+0x1a 9c52b038 806379d6 e10378a4 9c52b0bc e1174818 nt!CmpQuerySecurityDescriptorInfo+0x23 9c

我有一个WPF应用程序在客户端计算机上崩溃。我的初步分析表明,这是因为H/W加速,在注册表级别禁用H/W加速可以解决这个问题。现在我必须确定这是由H/W加速度引起的。我有可用的崩溃转储,有堆栈跟踪

9c52b020 80636ac7 9c52b0bc e1174818 9c52b0c0 nt!_SEH_prolog+0x1a
9c52b038 806379d6 e10378a4 9c52b0bc e1174818 nt!CmpQuerySecurityDescriptorInfo+0x23
9c52b084 805bfe5b e714b160 00000001 9c52b0bc nt!CmpSecurityMethod+0xce
9c52b0c4 805c01c8 e714b160 9c52b0f0 e714b15c nt!ObpGetObjectSecurity+0x99
9c52b0f4 8062f28f e714b160 8617f008 00000001 nt!ObCheckObjectAccess+0x2c
9c52b140 8062ff30 e1038008 0066a710 cde2b714 nt!CmpDoOpen+0x2d5
9c52b340 805bf488 0066a710 0066a710 8617f008 nt!CmpParseKey+0x5a6
9c52b3b8 805bba14 00000000 9c52b3f8 00000240 nt!ObpLookupObjectName+0x53c
9c52b40c 80625696 00000000 8acad448 00000000 nt!ObOpenObjectByName+0xea
9c52b508 8054167c 9c52b828 82000000 9c52b5ac nt!NtOpenKey+0x1c8
9c52b508 80500699 9c52b828 82000000 9c52b5ac nt!KiFastCallEntry+0xfc
9c52b58c 805e701e 9c52b828 82000000 9c52b5ac nt!ZwOpenKey+0x11
9c52b7fc 805e712a 00000002 805e70a0 00000000 nt!RtlpGetRegistryHandleAndPath+0x27a
9c52b844 805e73e3 9c52b864 00000014 9c52bbb8 nt!RtlpQueryRegistryGetBlockPolicy+0x2e
9c52b86c 805e79eb 00000003 e8af79dc 00000014 nt!RtlpQueryRegistryDirect+0x4b
9c52b8bc 805e7f10 e8af79dc 00000003 9c52b948 nt!RtlpCallQueryRegistryRoutine+0x369
9c52bb58 b8f5bca4 00000005 e6024b30 9c52bbb8 nt!RtlQueryRegistryValues+0x482
WARNING: Stack unwind information not available. Following frames may be wrong.
9c52bc00 b8f20a5b 00000005 85f4204c 85f4214c igxpmp32+0x44ca4
9c52c280 b8f1cc7b 890bd358 9c52c2b0 00000000 igxpmp32+0x9a5b
9c52c294 b8f11729 890bd358 9c52c2b0 00000a0c igxpmp32+0x5c7b
9c52c358 804ef19f 890bd040 86d2dad0 0000080c VIDEOPRT!pVideoPortDispatch+0xabf
9c52c368 bf85e8c2 9c52c610 bef6ce84 00000014 nt!IopfCallDriver+0x31
9c52c398 bf85e93c 890bd040 00232150 9c52c3f8 win32k!GreDeviceIoControl+0x93
9c52c3bc bebafc7b 890bd040 00232150 9c52c3f8 win32k!EngDeviceIoControl+0x1f
9c52d624 bebf3fa9 890bd040 bef2a28c bef2a284 igxpdx32+0x8c7b
9c52d6a0 8054167c 9c52da28 b915d000 9c52d744 igxpdx32+0x4cfa9
9c52d6a0 00000000 9c52da28 b915d000 9c52d744 nt!KiFastCallEntry+0xfc
通过查看上述数据,我如何确保碰撞是由H/W加速度问题引起的?我猜是
VIDEOPRT!pVideoPortDispatch+0xabf
表示渲染时出现错误。对吗


我正在使用WinDebug查看崩溃转储

在互联网上快速搜索,你会发现

igxpmp32.sys文件信息

process Intel Graphics Miniport驱动程序属于英特尔公司(www.Intel.com)针对Windows NT(R)的软件“英特尔图形加速卡驱动程序”

igxpdx32也应该来自英特尔。所以你对根本原因的猜测应该是正确的

因此,您可以联系英特尔支持部门,让他们分析转储,以确认这是否是已知问题


对于一个局外人来说,分析这样的转储几乎是不可能的,因为没有私人符号。

你有最新的图形卡驱动程序吗?@Mitch Wheat:我想没有。升级也可以解决这个问题。但我更感兴趣的是如何确定碰撞是由于H/W加速度造成的?这样我就可以很容易地判断何时从用户那里得到下一次崩溃转储。