WPF application using win32 dialogs on XP crashes - wpf

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.

Related

Visual Studio Code opens multiple instances

Two days ago I installed Visual Studio Code and it worked pretty fine. But now as I am opening Visual Studio Code it's opening multiple instances, how can I solve it..??
Edit: it seems Visual Studio Code opens every file present in the directory in another window how can I solve that..??
I had similar problems as well (SECOND ACTION - in my answer should solve your problem). My system was suddenly "laggy" as well, with no prior sign of significant damage. My windows self-restarted on its own, attempting to fix the problem but still didn't resolve it. When I use the command:
code .
in the comand line to open a folder in visual studio code (vscode) editor, it opens multiple instances of windows tab. Below is how I tackled the two problems:
Two things (Actions);
FIRST ACTION: (targeted: Laggy windows OS)
I used the command prompt(in Admin mode) to run the command: ”
sfc /scannow
This action fixed some corrupt system file and solved the laggy nature. I noticed significant improvement, possibly restoring it to previous performance level.
Check the Microsoft docs for more info.
SECOND ACTION: (Visual Studio Code opens multiple instances - should answer your question)
Open vscode editor, go to the setting and paste this in the search bar:
"workbench.editor.enablePreview": false
If you have this option marked, you should unmark it or set it to false depending on the interface you are presented and interacting with. This should stop vscode from running multiple instances and hopefully resolve your problem.

VS2012 crash when user control attempts to access file

I am building a windows forms application (C#). I have created a reasonably complex custom user control, works great. Problem is, when I add this control to my main form it crashes VS some time later.
After looking around about this I found the suggestion that I use two instances of VS, one to debug the other - this quickly narrowed in on the problem:
The custom user control contains a 30 second timer which saves some data to an XML file when it completes. As the program is not actually running, it is attempting to save the file to C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE , where it does not have permission (thus the crash).
This is an unusual problem, as when the application is running normally it will not be a problem (the file is set to save in the same directory as the executable). Is there a way to prevent the control from running while in design mode?

WPF app won't run in kiosk mode

I have a WPF application that is designed for a touchscreen kiosk. Users will not have access to a keyboard or mouse. The application runs fine when started normally from the program icon in windows. However, when it is set up to run automatically at startup (by replacing the Windows shell using a registry key), the application does not function properly.
The application reads an XML file that lists available videos, then displays buttons to show the videos. When run in "kiosk mode," it does not seem to have access to the files in its media directory (the XML file and presumably the videos as well). I suspect that because the application is running in place of the windows explorer, it is missing resources it needs for file access that are normally loaded by windows explorer.
I have not been able to find any info on this - there is plenty of info on how to get an app to run at startup, but not much on how to make sure it will actually function in that environment. The PC is running Windows 7 Professional.
Is my assumption about the problem correct, or is it likely something else (e.g. permissions - we checked the permissions, but maybe they operate differently when you replace the windows shell?) If it is because needed resources are not loaded, does anyone have pointers on how to make sure my app loads them?
Perhaps you have file access occurring via a file dialog? This might explain a bit further. What is the minimum functionality needed to create Shell Replacement for Windows?
because you have stopped windows default running explorer.exe , your program can not get access to default xml directory therefore you should specify the complete path for example like below:
stream = File.Open(#"C:\x86\Debug\xml.xml", FileMode.OpenOrCreate);

System.OutOfMemoryException and a few exceptions happen during application run, Visual Studio 2010 WPF C#

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.

OpenFileDialog crashes under Windows XP, but not Windows 7

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

Resources