C# 确定AccessViolationException DragDrop.DoDragDrop的原因

C# 确定AccessViolationException DragDrop.DoDragDrop的原因,c#,debugging,access-violation,C#,Debugging,Access Violation,我有一个WPF应用程序,当拖动操作启动时,它在一些带有AccessViolationException的计算机上崩溃 困难在于它只发生在我们构建服务器的构建上,并且在VisualStudio2010中本地构建时从未崩溃。所以我不能单步通过代码 我有以下资料: 我们正在使用.NET4.0 仅当应用程序作为64位进程运行时崩溃,32位就可以了 仅来自生成服务器的生成崩溃 不会在每台电脑上崩溃,只是在我们这里的一小部分笔记本电脑上。顺便说一下,它们都是相同的型号 以及硬件配置。都有 Windows7

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

困难在于它只发生在我们构建服务器的构建上,并且在VisualStudio2010中本地构建时从未崩溃。所以我不能单步通过代码

我有以下资料:

  • 我们正在使用.NET4.0
  • 仅当应用程序作为64位进程运行时崩溃,32位就可以了
  • 仅来自生成服务器的生成崩溃
  • 不会在每台电脑上崩溃,只是在我们这里的一小部分笔记本电脑上。顺便说一下,它们都是相同的型号 以及硬件配置。都有 Windows7,有的有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()
更新:
通过反复试验,我能够确定导致这次崩溃的确切代码行,它似乎是完全有效的。作为一个实验,我禁用了包含违规代码行的方法的代码优化,应用程序不再崩溃。

只是一种预感,但由于您指出您正在优化代码,并且使用32/64位混合环境:

  • 在x64位环境中验证生成服务器
  • 验证客户端是否具有正确的.Net环境版本
  • 验证运行应用程序的客户端是否运行正确的版本,即64位仅由win7 x64系统运行,反之亦然
  • 请确保清除服务器临时目录,临时目录中以前的版本可能会导致类似这样的问题
  • 还要注意的是,微软开发人员在隔离两个环境的方式上很愚蠢,并且注册表项/程序文件等没有存储在程序指定的位置。这是我在公司创建的一些应用程序中遇到的一个主要障碍

    我还相信剪贴板和拖放调用是STA(单线程Apratements)调用。崩溃可能是由于STA和MTA之间的冲突造成的。Main()函数是否用[StatThread]修饰


    我个人认为这篇关于64位迁移的文章很有用:

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

    稍后,您可以使用debugdiag创建一个crashdump,并检查firstchance和secondchance异常,以获取有关该问题的更多信息

    您好


    伊恩

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

    在MS.Win32上。不安全的方法

    这通常意味着.NET工程师试图告诉您:
    “嘿,这不是我们写的,它崩溃了。”

    AV异常是最糟糕的,您应该知道问题可能来自系统中完全不同的部分

    通常发生的情况是,您意外地访问了一个您无权访问的内存位置,程序继续正常执行,但是稍后另一种方法尝试访问该内存位置,并错误地读取了不正确的数据,从而导致错误


    为了进行调试,我建议您利用微软提供的一种工具来检测deap损坏。我多次使用它,它为我节省了数小时甚至数天的调试工作。

    您是否尝试过从本地系统调试和发布版本之间的区别?可能是一些#if调试语句导致了不同的行为?您使用的是哪个版本的框架?噢,我想到了一些东西。您的事件处理程序是否偶然序列化了任何内容?这可能会在生成生成输出中未包含的序列化程序集时导致问题。或者,当没有授予足够的权限时,它是否访问任何文件或任何可能导致此问题的内容?也许是wow6432节点的注册表访问权限?@叹气,你能把你的代码显示在你调用DoDragDrop的地方吗?你提到一个更新,你到底发现了什么?我们能看到经过优化的代码吗?