确定AccessViolationException DragDrop.DoDragDrop的原因

时间:2011-06-14 08:10:35

标签: c# debugging access-violation

我有一个WPF应用程序在启动拖动操作时在某些带有AccessViolationException的计算机上崩溃。

困难在于它只发生在构建服务器的构建上,并且在我在Visual Studio 2010中本地构建时永远不会崩溃。所以我无法单步执行代码。

我有以下信息:

  • 我们正在使用.net 4.0
  • 当应用程序作为64位进程运行时,只会崩溃,32位就可以了。
  • 仅从构建服务器崩溃构建。
  • 不会在每台计算机上崩溃,只是在我们这里的一小部分笔记本电脑上。顺便提一下,这些都是同一型号 和硬件配置。都有 Windows 7,有些还有sp1,有些 不。

我应该采取什么措施来诊断这个问题?

这是来自崩溃的堆栈跟踪,它似乎发生在非托管代码中:

at MS.Win32.UnsafeNativeMethods.DoDragDrop(IDataObject dataObject, IOleDropSource dropSource, Int32 allowedEffects, Int32[] finalEffect)
at System.Windows.OleServicesContext.OleDoDragDrop(IDataObject dataObject, IOleDropSource dropSource, Int32 allowedEffects, Int32[] finalEffect)
at System.Windows.DragDrop.OleDoDragDrop(DependencyObject dragSource, DataObject dataObject, DragDropEffects allowedEffects)
at Acquire.Common.UI.Behaviours.DragDropBehaviour.StartDrag(RoutedEventArgs e)
at Acquire.Common.UI.Behaviours.DragDropBehaviour.AttachedElementMouseMove(Object sender, MouseEventArgs e)
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler, Object target)
at System.Windows.EventRoute.InvokeHandlersImpl(Object source, RoutedEventArgs args, Boolean reRaised)
at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender, RoutedEventArgs args)
at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)
at System.Windows.Input.InputManager.ProcessStagingArea()
at System.Windows.Input.InputProviderSite.ReportInput(InputReport inputReport)
at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x, Int32 y, Int32 wheel)
at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.WrappedInvoke(Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Application.RunInternal(Window window)
at System.Windows.Application.Run()
at Acquire.Mica.Application.App.Main()

更新 通过反复试验,我能够确定导致此崩溃的确切代码行,并且它似乎完全有效。作为一项实验,我禁用了包含有问题的代码行的方法的代码优化,并且应用程序不再崩溃。

4 个答案:

答案 0 :(得分:1)

AV异常是最糟糕的,您应该意识到问题可能源于系统中完全不同的部分。

通常发生的是您意外访问了您无权访问的内存位置,程序继续像往常一样执行,但稍后另一种方法尝试访问该内存位置并通过读取错误数据导致错误错误地把它放在那里。

要进行调试我建议您利用gflags这一微软提供的工具来检测deap损坏。我多次使用它,如果不是几天的调试工作,它就节省了我几个小时。

答案 1 :(得分:0)

只是预感,但既然你表示你正在优化代码,并使用混合的32/64位环境:

  1. 验证构建服务器是否为x64位环境。
  2. 验证客户端是否具有正确的.Net环境版本。
  3. 验证运行应用程序的客户端是否正在运行正确的版本,即。 64位仅由win7 x64系统运行,反之亦然。
  4. 确保清除服务器临时目录,临时目录中的先前版本可能导致奇怪的问题,例如此。
  5. 另请注意,Microsoft开发人员在将这两种环境隔离开来时是愚蠢的,并且注册表项/程序文件等不会存储在程序指示的位置。这是我在公司创建的一些应用程序时遇到的主要绊脚石。

    我也相信剪贴板&拖放调用是STA(单线程apratments)调用。崩溃可能来自STA与MTA之间的冲突。你有用[STAThread]装饰的Main()函数吗?

    我个人认为这篇关于64位迁移的文章很有用:http://www.codeguru.com/cpp/misc/samples/basicprogramming/article.php/c16093/Seven-Steps-of-Migrating-a-Program-to-a-64bit-System.htm

答案 2 :(得分:0)

首先检查机器上是否安装了所有更新。

稍后您可以使用debugdiag创建故障转储并检查firstchance和secondchance异常以获取有关此事的更多信息。

问候,

伊恩

答案 3 :(得分:0)

我要做的第一件事就是更新这些笔记本电脑的显卡驱动程序。

在MS.Win32.UnsafeNativeMethods ..

这通常意味着MS .NET工程师试图告诉您: "嘿,我们没有写这个并且它崩溃了。"