Sometimes support reply: Your machine is hosed
I just got the following stack trace as part of the profiler error reporting:
System.Windows.Markup.XamlParseException: Failed object initialization (ISupportInitialize.EndInit). Attempted to read or write protected memory. This is often an indication that other memory is corrupt. Error at object 'HibernatingRhinos.Profiler.Client.MainWindow' in markup file 'EFProf;component/mainwindow.xaml' Line 235 Position 3.
---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at MS.Win32.UnsafeNativeMethods.GetOpenFileName(OPENFILENAME_I ofn)
at Microsoft.Win32.OpenFileDialog.RunFileDialog(OPENFILENAME_I ofn)
at Microsoft.Win32.FileDialog.RunDialog(IntPtr hwndOwner)
at Microsoft.Win32.CommonDialog.ShowDialog()
at HibernatingRhinos.Profiler.Client.Model.LicensePromptPresenter.AttemptToGetLicenseFile()
At this point, I am sort of scratching my head. I am making a call to a perfectly legit Win32 method. And I am getting AccessViolationException.
Pretty much the only things that I can think of that can cause this issue are:
- Explorer is broken.
- There is some sort of explorer extension installed that is reacting badly to OpenFileDialog.
Either way, this is one of the cases where there doesn’t seems to be anything that I can do.
Comments
You can get memory dump file from this crush and check what's going on. But certainly you'r right, it seems like the problem lies outside your app. Regards.
Do you find that even once you explain that their computer is bust not your software, they still want you to fix it?
Do you use any unmanaged calls/code directly elsewhere in your app?
[)amien
Richard,
Sometimes, yes.
Damien,
A few DllImport calls, yes.
Do you use the RestoreDirectory property of OpenFileDialog class? Maybe the user opened a file in another application and the directory was stored. If the directory was on an external disk it could be a problem if the drive no longer exists.
I got the same error because of DEP (Data Execution Prevention).
Maybe this helps you out, too:
editbin.exe /NXCOMPAT:NO <your
blogs.msdn.com/.../...mpat-and-the-c-compiler.aspx>
In order to cut down on support calls you can at least tell the user that the problem can probably be fixed by rebooting when an AccessViolation occurs. On the other hand every customer contact is an opportunity to enhance the relation with him.
@tobi: Except it probably can't be fixed that way. Rebooting isn't magic, you know.
Perhaps his memory is corrupt or damaged :)
I wonder what's in 'EFProf;component/mainwindow.xaml' Line 235 Position 3.
Sometimes anit-virus software can cause this behaviour with .NET.
@Configurator: As a guess: The main window of the application? :)
What Mitch Denny says rings true... It's probably an over sensitive bit of AV software.
The problem clearly isn't your code, Microsoft standard open file dialog is causing that error.
If it's not reliably thrown by your code every time when he goes down that code path, the problem is their hardware. Nobody likes hearing that though, but since you're probably speaking with a developer they may be more understanding.
I would strongly suspect a shell extension or something like a misconfigured/installed VirtualCloneDrive/DaemonTools.
You know, what works for me is if I compile against x86 and NOT AnyCpu. Let me guess, you're running an x64 OS, right?