确定AccessViolationException DragDrop.DoDragDrop的原因

Question

我有一个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()

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

Answer 1

只是一种预感，但既然您表示您正在优化代码并使用混合 32/64 位环境：

1. 验证构建服务器是否为 x64 位环境。
2. 验证客户端具有正确版本的.Net 环境。
3. 验证正在运行该应用程序的客户端正在运行正确的版本，即。64 位仅由 win7 x64 系统运行，反之亦然。
4. 确保清除服务器临时目录，临时目录中的先前构建可能会导致诸如此类的奇怪问题。

另请注意，微软开发人员隔离两个环境的方式是愚蠢的，并且注册表项/程序文件等未存储在程序指示的位置。这是我在公司创建的一些应用程序中必须克服的主要障碍。

我还相信剪贴板和拖放调用是 STA（单线程设备）调用。崩溃可能是由于 STA 与 MTA 之间的冲突造成的。您是否有用 [STAThread] 装饰的 Main() 函数？

我个人发现这篇关于 64 位迁移的文章很有用：http://www.codeguru.com/cpp/misc/samples/basicprogramming/article.php/c16093/Seven-Steps-of-Migration-a-Program-to-a -64位-系统.htm