RE: System.AccessViolationException in .NET 2.0 application


I have searched this exception and call stack in internal database and
found 2 reported records with the same error. However, both 2 records are
closed as "can not reproduce".

Based on the call stack, there is an AV exception in the
UnsafeNativeMethods.GetOpenFileName code which wraps Win32 GetOpenFileName
API in comdlg32.dll. So the exception is generated in Win32 side while the
Net exception call stack only shows the managed call stack. It is almost
impossible to find out the root cause without using unmanaged debugging to
dig into GetOpenFileName.

Can you reproduce your customers' problem on your side? If so, please feel
free to provide the sample project. I will help to use the windbg to
perform Win32 debugging to find out which x86 instruction is accessing
invalid memory region. You may send the sample project to me at:
jetan@xxxxxxxxxxxxxxxxxxxx(remove "online.")

Just a guess, since the calling of GetOpenFileName API comes from .Net
Framework code, I would not suspect the code of GetOpenFileName or
parameters passed from .Net. I suspect certain 3rd party software may have
corrupted your memory region or changed the CPU registers, which caused the
CPU to read/write an invalid memory region. You may ask your customer to
turn off any anti-virus softwares and screen translation softwares. These
softwares may inject code/dll into any application memory space for hooking
purpose. A more technical way is listing all the modules/dlls in your
application process in problematic machine to examine if there is any
abnormal module/dll(that is neither Microsoft dlls or your application
dlls). You may ask the customer to download Process Explorer to examine the
dll list:

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
Get notification to my posts through email? Please refer to

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
This posting is provided "AS IS" with no warranties, and confers no rights.