I have a winform Application and there is a code to open Save as Dialog box.
DialogResult result = saveFileDialog1.ShowDialog();
The program very well runs on Windows XP but on Win 7 the application hangs, the debugger does not return from this line of code. The Event Viewer detail reads as follows
The Program Sample.exe stopped interacting with windows and was closed
Has anyone been through this problem?
Update
It seems that the error was caused due to the code running on another thread which I have nowremoved .Although it is not recommended to access UI elements from another thread I am surprised why I didnt get this error while running on XP ??
Are you setting the InitialDirectory property of the dialog?
If you are, try setting it to another location if you are not you could try setting it.
If this is defaulting to a network path, it could be taking the time opening that path?
This could be result of corrupted file system or hard disk. When save dialog is invoked, it will try to get the list of hard drives , logical drives and folders. If any of it is corrupt, it will hang/throw an exception.
Try running same app in different Windows 7 machine
Did you run System File Chccker (SFC) scan on the windows 7 which would scan for corrupt system files on the computer and replace them.
http://support.microsoft.com/kb/929833
Related
I'm new to c#. Antivirus deleted the mySolutionName.exe file out of the /debug directory and now I cannot execute my code. I'm concerned that anything I do may make the issue worse.
When I press F5 I get an error of:
CS2012 C# Cannot open for writing --> C:\Users\me\source\repos\MyApp\MyApp\obj\Debug\MyApp.exe''
Can someone please tell me how to rebuild the file so that I can continue developing?
after your edit:
Your program is probably still running outside of the debugger.
You need to use the task-manageer to kill all instances of MyApp.exe if this doesnt solve your issue a reboot should do the trick as well
So why is this happening?
Most liky your application is somewhere stuck on a blocking function or in a never ending loop. maybe there is even a seperate thread still operating that you forgot to close. We lack some information to tell yout that for sure. But to find out what is happening you can close your window while running in debugger mode and see if the application properly closes. if it doesnt you can hit pause and see where the program is stuck and resolve this issue by ending the task/loop/whatever in your OnClosing function of your window.
A good way to solve this issue is looking which process currently accesses the file.
A tool to do that is Microsoft SysInternals Process Explorer. It has a feature called "Find handle or DLL ..." which can be accessed by Ctrl+F.
The result will show the process which accesses the file. You can then judge whether it's Antivirus or something else that prevents you from writing to the file. If possible, you can then take an action in that program to release the file.
Example: a program is accessing my powerpoint presentation, which has the term "Schulungen" in its file name.
Process Explorer figures out: it's open in Powerpoint.exe, so I can simply close the file in Powerpoint - problem fixed.
I am building a .net 4.5 (c#) app and packaging it with Squirrel for Windows.
As expected, the releasify command creates one Setup.exe file and one Setup.msi. The Setup.exe installs the app as expected on the two windows 10 computers I had access to.
On the windows 7 I used to build the app though, when I try to open Setup.exe, the window where I double clicked the icone goes in "please wait mode" (with the blue progress circle instead of the usual mouse pointer) forever. If I check the processes open at that point, I see three Setup.exe that I cannot kill with the kill process button or via Taskkill command. And all I can do at that point to kill them is pretty much rebooting.
As to the Setup.msi, it seems to do nothing I can see (tells me something like "checking requirements", and once it has, it just closes with no visible effect).
Any idea about what's going on or how I could find out?
Apparently years later this keeps hitting people so I'm posting the answer I had first put in the comments:
Deactivating my antivirus solved the issue >< I wish Avast had told me "hey I'm blocking this" and saved me a few hours
I have a user that has Windows 10 and is saying that their mapped drives are not showing up on one machine specifically and only in my program. I am using a standard Microsoft.Win32.OpenFileDialog to allow the user to browse to a file to open. On this machine they sent me a screen shot where there is one windows explorer window open that shows the mapped drives just fine, then the open dialog in my program that doesn't show them at all (simultaneously). The really strange thing is that other machines on their network do not have the same issue, they show the drives in my program as well.
I'm not sure even where to start with this. I googled it but didn't really turn up anything; I also searched here and didn't find anything. Does anyone know if there is some obscure setting or something that could be causing it not to show mapped drives?
If you are attempting to run the program as an administrator you will not be able to see mapped drives.
Thanks to #jcolebrand who said this:
Are they running it as an administrative user? If so, mapped drives don't run across UAC elevations, and this could be what you're running into. – jcolebrand Sep 25 '15 at 21:15
In a comment above.
so this is kind of a weird error. On one machine from one of our customers (Windows XP SP3) our program crashes when trying to open a filter dialog via ShowDialog().
What happens: The user works as expected he/she does nothing unnormal or wrong and everything he/she does is/was tested on several machines (ranging from Win XP 32 bit to Win 7 64 bit).
Now, after some time he/she want's to use the filter dialog (which he/she did at that point like a dozen times) and the application crashes. You get that wonderful "$applicationname caused a problem and has to be terminated" message from Windows XP, beneath it you can see the filter dialog, partially build (meaning: you can see the window, a scroll bar and transparent 'holes' where the text controls/labels should be.
In the Windows eventviewer you can see an entry like this
Event ID: 1000
Source: .NET Runtime 4.0 Error Re (maybe something stands behind this and it says 'Reporting'?!)
Faulting application $applicationname.exe, version $versionnumber,
stamp $someRandomNumbers, faulting module ntdll.dll, version
5.1.2600.6055, stamp 4d00f27b, debug?0, fault address 0x00446da
Now, what weirds me out: The position where the dialog is opened via ShowDialog, is embedded in 2(!) try...catch blocks. How is it possible for the application to crash? There aren't even logfileentries (something that is done in EVERY catch block we've in that program and it's always the first thing we do) about this crash.
I already uninstalled the application and .NET 4 from that machine, rebooted installed everything again, installed Windows Updates and rebooted again. Same result.
*edit
just noticed something: When I close the message from microsoft, an additional entry in the eventviewer is created:
The process was terminated due to an unhandled exception I guess that's the meaning in english, since the original message is in another language I had to translate
Exceptioncode: c015000f, address 7c9546DA address is always the same
As #Hans said, it's caused by incorrect use of the De/ActivateActCtx winapi functions.
I met the same problem when I write a VB App. using my ActiveX Contrl(MFC). I place a dialog variant in the control class definition.
Like below:
CMyDlg dlg;
So when does the dialog initilized is not in my control. And that made the same issue as you. When the control should be displayed, the error appears.
I have a WinForms app deployed to multiple machines in the same office. Up until this Monday, all users in the office used the app without issue and used the OpenFileDialog to select files to import. One machine had lots of updates to other apps and now freezes when our app tries to show the OpenFileDialog. It shows the OpenFolderDialog fine; though I failed to try the SaveFileDialog. Just to repeat, it worked last week, our app was not updated, but it freezes on one machine this week whereas it works on all other machines in the office.
The machine in question has another .NET app installed and I verified the OpenFileDialog opens without issue in the other app.
Any ideas as to why the OpenFileDialog would freeze on one machine? Any ideas on how to fix this? We could try reinstalling without knowing the cause, but I figured it is better to investigate why to prevent it from happening again.
This machine may have connected to a network resource in the past, which is no longer available. OpenFileDialog could be waiting for the network resource to respond, which will take several minutes to timeout.