I've got a strange problem I haven't seen before. I can open an OpenFileDialog in Windows 7 without any problems. However, when I try my app on Windows XP, calling OpenFileDialog.ShowDialog() immediately crashes the application. It just vanishes! When running from the debugger, I don't get any unhandled exceptions. If I wrap the code in a try/catch block, nothing gets caught. I have also checked all thrown exceptions in Debug -> Exceptions, but nothing pops up. I'll try some of the other suggestions in the answers below and will report back.
Does anyone know how to resolve this problem? I found a post about something similar, but it was the opposite problem. I'll try tweaking the desktop settings to see if it's related to that, but I am dubious.
EDIT -- as a sanity check, I wrote a test WPF application that displays an OpenFileDialog directly via the main window as well as another Window that can be displayed by the main window. It totally works fine under Windows XP. So now I'm really confused. I have verified that I'm not doing something stupid like trying to display the dialog from a worker thread. The OpenFileDialog displays briefly, then disappears along with the application.
EDIT -- I'm going to try to reproduce this problem on another XP computer. For now, I'll try Windows XP mode and we'll see what happens.
I got a similar error when a DLL crashes when I open a OpenFileDialog. It turned out that OpenFileDialog changed the working directory so my dll tried to write to a relative file that did not exist.
Do you see any "First Chance" exceptions in the Output? Any entries in the event log? Does the default path you're using exist on the XP machine?
Try adding a handler to the App Domain's UnhandledException
Does the same happen when you use a brand new, stock FileOpenDialog without any tweaks? What about from a brand new app which does nothing but show a file open dialog?
See Galet's post
I cannot tell you what exactly the problem is, but here's what you could do to get a clue what's really happening. I assume you're using VS2008 or 2005.
1.Switch to release mode
2.Go to Debug\Exceptions, and mark all "Thrown" exceptions, like illustrated here: http://vvcap.net/db/JbWS_tzy2IpBoI7R7amm.htp
3.Run executable in debugger, ignore the warnings from VS that there's no debug info
It does seem that there's a win32 exception thrown some time during execution, but this way or another, you will get one or more messages from debugger explaining what kind of exception happened and where. In most cases those messages make it pretty clear what exactly went wrong
EDIT: One thing I forgot to mention is that unmanaged debugging must also be turned on, such like here (when you start program directly from IDE) or here (when you attach to running process)
link|edit|flag edited Apr 12 '09 at 22:32
answered Apr 10 '09 at 19:01
galets
1,2201924
Related
I upgraded from 10.3 (Rio) to 10.4 (Sydney) (with side-by-side installs), now having IDE docking exception, e.g.
Loading the desktop from "C:\Users\gary.walker\AppData\Roaming\Embarcadero\BDS\21.0\Default Layout.dst" for doc host windows "DockSite3" failed with message:
"EAccessViolation: Access violation at address 50165CBF in module 'rtl270.bpl'. Read of address 33DEEBFF"
Deleting all .dst files has resolved the issue in at least one case (a coworker).
Also, when attempting to debug a program, I was having a hard failure during debug startup that prevented debugger use, before application began execution. I resolved this problem by copying my Default desktop to my debug desktop.
Another friend had pretty much the same issue and was able to fix it, unfortunately he does not know how he fixed it.
Question is does anyone know how to fix this?
I am still waiting for an answer from Embarcadero and this is causing us real problems at the moment.
I received an answer from Embarcadero support.
It fixed the problem for me until I adjusted my desktops to the way I wanted them and them - still better than nothing. I suspect there is no solid work-around at this point in time. But, this may work well as long as you are not frequently changing your desktop layouts.
There were display layout changes introduced in 10.4.1 that cause the errors that you are seeing.
Shut the IDE down
In Windows Explorer navigate to: %AppData%\Embarcadero\BDS\21.0
Delete the *.dst files at that location (you can back them up first if desired)
In Windows Explorer navigate to the product's \bin directory. The default location is: 4. C:\Program Files (x86)\Embarcadero\Studio\21.0\bin
Copy the three default *.dst files from this location to the location in step 2
Start the IDE as normal
When I launch my WPF application and when it goes to InitializeComponent function call of one user control, it silently quits and only leaves one message in the output window saying Managed (v4.0.30319)' has exited with code -1073740771 (0xc000041d). When I say "silently", I mean there is no exception is caught even if I wrap this InitializeComponent call with a try-catch block (that's how I normally find where the problem is)
Here is what I did: in this application project we need to use a reference Microsoft.Office.Interop.Owc.dll, with version number 10.0.4504.0. Since it is an interop library, when I added this reference in VS2012, it automatically sets the property Embedded Interop Types as true, which I assume means it will not keep an individual dll in the output folder but instead embed this library into the main output (at least this is how it seems in our other references, for example, Microsoft.Office.Interop.Outlook.dll). However, when I launch the project, it throws an XamlParseException saying:
"Could not load file or assembly 'Microsoft.Office.Interop.Owc, Version=10.0.4504.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system
cannot find the file specified.":"Microsoft.Office.Interop.Owc, Version=10.0.4504.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35""
It seems that the reference was not embedded(or the version is not currect. But I verified that the reference version is indeed 10.0.4504.0)
Next I copied this dll directly to the output folder bin\Debug\, to make sure that it can find this library. This time the exception is not thrown, but the whole application just silently quits as I described in the beginning. I tried to google the code -1073740771 (0xc000041d) but there is no article about it. I tried to set the Embedded Interop Types to true/false but the problem is the same.
UPDATE:
I'd like to add more description here. As mentioned above, the problematic library is OWC(Office Web Component)10. I followed this link to make OWC work with VB.NET desktop application: HOW TO: Handle Events for the Office Web Components in Visual Studio .NET. But this official article is so old so I had to make a lot of changes to compile the wrapper dll(mainly because of namespace mismatch). Then when I add the reference to the actual interop library Microsoft.Office.Interop.Owc, if I follow the default setting and let the Embedded Interop Types as True, at runtime it will complain (throw a XamlParseException) that the assembly cannot be loaded (see description above). What the hell? I thought make it as "embedded" would guarantee this library will be found. Then I copy this dll to the output folder, then I have this silently quit problem. But it might be worth mentioning that this time the output window shows the Microsoft.Office.Interop.Owc.dll is indeed loaded. Actually it is the last message before the managed has exited message. So it must still relate to this library.
All of this only happens with OWC10. There is actually a similar way to do that in OWC11(the latest, but unfortunately still pretty old version since it came with Office2003): HOW TO: Handle Events for the Office 2003 Web Components in Visual Studio .NET. But it actually works and the control is displayed on my application. It is because of some other reason that I wanted to try OWC10 instead of OWC11
When I launch my WPF application and when it goes to InitializeComponent function call of one user >control, it silently quits and only leaves one message in the output window saying Managed
(v4.0.30319)' has exited with code -1073740771 (0xc000041d). When I say "silently", I mean there is >no exception is caught even if I wrap this InitializeComponent call with a try-catch block (that's >how I normally find where the problem is)
Next I copied this dll directly to the output folder bin\Debug\, to make sure that it can find this >library. This time the exception is not thrown, but the whole application just silently quits as I >described in the beginning. I tried to google the code -1073740771 (0xc000041d) but there is no >article about it. I tried to set the Embedded Interop Types to true/false but the problem is the >same.
I had exactly the same thing happening to me today, "has exited with code -1073740771 (0xc000041d)." (This happened in both a VB and C# .NET WinForms application for me). I tried debugging and saw I never even got into the Form_Load code block.
I "solved" this in the end by running visual studio as an administrator (and then just opening & building and running the project via the menu).
This is a win8 security issue and it isn't well explained anywhere.
(I got distracted and just opened up a specific project straight out of my task bar/solution file which caused this to happen to me).
You've probably found this out by yourself by now, hope you didn't lose any hair over it :)
Just pointing this out for other people who might have this error occuring somewhere.
Also had this issue, the 'silent' exit with code -1073740771 (0xc000041d) on x64 platforms, on x86 platforms everything was OK.
Part of my application is unmanaged C++, another part is C#. It turned out that my C++ code was not completely ready for the x64 platform. The following change fixed the issue in my case:
// before
g_OrigWndProc = reinterpret_cast<WNDPROC>(::SetWindowLongPtr(hWnd, GWLP_WNDPROC,
reinterpret_cast<LONG>(WindowProc)));
// fixed version
g_OrigWndProc = reinterpret_cast<WNDPROC>(::SetWindowLongPtr(hWnd, GWLP_WNDPROC,
reinterpret_cast<LONG_PTR>(WindowProc)));
So, the generic recommendation is to verify that your code is completely ready for the x64 platform.
(see update below)
While running within the VisualStudio 2010 environment, I can easily tell if my Winform application causes an exception. I just have to go to Debug | Exceptions and make sure that both columns of checkboxes are checked. I then run the application and if any exceptions then I get dropped straight into the offending piece of code.
How do I determine exceptions during testing, when I give test build to a tester. I do not want the tester to run within Visual Studio, just as a regular user. I still want to know if there are exceptions and the pertinent details.
Obviosualy, I should be able to control the process, so that when the code gets released normal execution happens.
Yes, I know about and use try/catch blocks, but I am talking about a method similar to Visual Studio exception catcher and reporter, just possibly compiled into the product and used for deployment to beta testers.
Maybe Visual Studio has such a feature, in which case where and how to set up, or possibly a third party component.
[Update:
I added two sub-questions, which you can find at Unhandled Exception next line or exit.
The solution mentioned below sounds great and with a tweak probably works, just not at the moment.
Inside the Visual Studio both 2010 and now 2012 works great. The exception handler gets called, okay after VS breaks at the line and I say to continue. I decided to test outside the VS2012 IDE, good thing for that. The OS traps the bug, shows the standard an "An Unhandled Exception Occurred" dialog giving the details along with a continue and quit buttons. Selecting continue, just continues the application with no trapping into my uber exception handler. Selecting quite, whites-out the application and displays the standard close window dialog. The quit button also does not call my uber handler.
The purpose is so that my exception handler gets called. I do not need an uber exception handler if I am working inside the VS2012 IDE. The purpose of the handler is for end users and beta testers, namely anyone other than myself and who will not have my development station.
So unless I am missing something, the question is still open.
There are code samples in the other question, enough to copy and paste and create a test application in a couple minutes time.
]
Thanks in advance,
Sarah
I don't know of any automagical ways to reports error in Visual Studio but here is what I do.
Hook into the UnhandledException event for the application.
Use a logging framework like nLog or Log4Net to log the exception and other data you get from that event. Or just write to a text file.
Upload that data either from within your application or have the beta-tester send it to you.
Okay, the Google Uberlord took pitty upon me and I found this wonderful article solving the problem. Praise to the almighty Google.
Here is the link:
http://www.switchonthecode.com/tutorials/csharp-tutorial-dealing-with-unhandled-exceptions
Basically, JRadness had the right idea, just slightly in error. He should have used
Application.ThreadException +=
new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
rather than
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
The author on Switch on the Code talked of three methods, the first of which is what JRadness proposed and does not work for Windows forms.
The autor even solved my other question of Continue and Abort. The OS got bypassed.
Yeah!!
We have a WPF application that was developed on Windows 7 using VS 2010 and .NET 4.0 framework.
I have created an install package for it using the Visual Studio Installer.
When running on XP it appears to go into a bad state after using the win32 OpenFileDialog. It took me a while to track this down, as it doesn't fail right away. The dialog appears, you select the file you want to open, it opens up and is displayed on the screen. I was using it for about two minutes and then it crashed. I get the message that my program has encountered a problem and needs to close.
I can now run my application, open a file and make it crash right away, since a specific action always makes it crash. It does on any file I open, even a new one.
So I tried opening the same file without using the OpenFileDialog, I have a MRU list that I selected the file from, and it works flawlessly. I have not been able to make it crash.
Anyone experience similar behavior or have any ideas?
Since I do not have a debug environment on the XP machine I tried putting in some tracing statements within the application to write out to our log file where it is and what value some variables have. The really strange thing is that as soon as the OpenFileDialog.ShowDialog method is called all writing to our log file stops. I am just using standard file I/O and actually open, write and then close the file for every log message. This makes it difficult to debug this way, but also further supports the fact that something is gone wrong in the environment.
I have tried on four different XP machines, all with the same results.
I just discovered this problem today, and I had no idea what caused this problem. My project had been developed for few months.
I have a project(solution), with several projects in there, it works well if I write and debug, by pressing F5.
The problem occur is when I press Ctrl+F5 (to skip debug mode), or run directly from double click the exe, it crashed. The errors dialogs that pop up every times are different, but OutOfMemoryException is the most frequent one.
I had checked to make sure all my projects are .Net 3.5
I put a MessageBox.Show("something") at the beginning of my main project constructor, but it never reach.
I use some registry cleaner to clean/fix my registry, scan for viruses.
I had try to read the meaning of each error and exception, but still no clue why it happen.
These are a series of screenshots if I press Ctrl + F5. (FutureGenerator is some random name I gave to my project.)
Series of screenshot if I run the app from my debug folder, FutureGenerator.exe
I suspect this is caused by framework crashed during Windows Update, but I removed those update that I performed recently, still same. The exe file works on other non development PC, but I don't want to reformat my PC or reinstall my VS, yet, because it's a painful process.
Any idea, anyone?? Million thanks.
You mention v3.5 but the very first screenshot is about v4.
Try repairing your Framework 4 and/or VS2010
I found the problem. It's actually because I added FutureGenerator.exe into Application Verifier by Microsoft. The verifier only support debugging testing.
After I removed FutureGenerator.exe from the Application Verifier, everything's ok.