确定AccessViolationException DragDrop.DoDragDrop的原因

| 我有一个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 个回复

恋卡

AV异常是最坏的情况，您应该意识到问题可能源自系统中完全不同的部分。通常会发生的情况是，您意外访问了无法访问的存储位置，程序继续照常执行，但是稍后另一种方法尝试访问该存储位置并通过读取错误的数据位置而导致错误因为失误。为了进行调试，我建议您利用gflags的优势，gflags是Microsoft提供的用于检测deap损坏的工具。我使用了几次，即使没有几天的调试工作也节省了我几个小时。

盛虱

只是一个预感，但是由于您已指出要优化代码，并使用混合32/64位环境：验证构建服务器是否为x64位环境。验证客户端具有正确的.Net环境版本。验证正在运行该应用程序的客户端正在运行正确的版本，即。仅由win7 x64系统运行64位，反之亦然。确保清除服务器的临时目录，以前在临时目录中进行的构建可能会引起诸如此类的奇怪问题。还应注意，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 -64位系统.htm