I'm running Python 2.7 with ArcGIS Desktop 10.1 on Windows for Server (2 Xeon 2.13 Ghz processors).
Is it possible to suppress or automatically close the dialogue box from Windows that says "python.exe has stopped working" when python crashes? I have a continuously running, multiprocessing script that sometimes crashes for unknown reasons (working on that). When I click to close the crash report window, the script restarts and everything is okay. I want this to happen automatically until I can track down what is causing the crashes.
Thanks very much!
Doug
Procedure for disabling the Windows Debugger dialogue box found here:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb204634(v=vs.85).aspx
This prevents the debug dialogue box that requires the user to click [Debug] or [Cancel] if python crashes.
However, there is now another Windows dialogue box that says "python.exe has stopped working. Please close the program" with a button [Close Program]. Sheesh!
The dialog you refer to is part of Windows Error Reporting.
The exact method varies between editions of Windows (Windows 7 instructions here, Google will happily provide for other versions...), but if you disable this feature of Windows, your crashes will happen a lot faster(!).
This is an simply an arcpy bug. You can try to avoid using the steps that are causing the crash, but it generally happens under different tools when used to process through a long list of data.
The only workaround I have found is to make my script save its progress along the way to disk so if you restart the process, it knows where to pickup from.
If you then disable windows debugger message by altering the registry (see below), you can then just repeatedly execute the script in cmd.exe until it completes the entire batch without having to close the process manually every time in between.
I know this is an awful workaround, but it is quite uncommon to have a python library kill off the python interpreter.
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"
Related
I'm trying to run a legacy VB6 application on Windows 10. I'm using creating an .sdb shim file which detects the application's .exe using the Compatibility Administrator tool found in the Windows ADK. Whenever the .exe runs, the screen resolution is resized to a specific resolution. When the .exe stops, the resolution returns to normal.
The Compatibility fixes I'm using are "ForceDisplayMode" with parameters to display at the legacy app's old resolution. And also "ForceTemporaryModeChange" which will revert the screen resolution back to normal.
One problem I'm having is that when the application is open, if I close my laptop lid and reopen it, the .sdb stops working (windows doesn't log out). If I log out, the old resolution is maintained as expected. I'm trying to figure out if there's an option to maintain the .sdb's resolution, or if this is an oversight on Microsoft's end?
Ok, in the off chance that anyone has this incredibly obscure problem in the future, the solution was apparently to disable tablet mode on Windows 10 1809. That solves the .sdb shim being undone by closing the lid on my SP3/SP6s.
Edit: Ok, turns out that was not the solution. It was just coincidence, so I've uncheckmarked this answer. We had an image that didn't have this problem but then later images reverted this behavior. Still don't know why this occurs.
Edit 2: I still don't know why this occurs but I have a few observations that may help someone. I'm on Windows 10 LTSC Version 1809 Build 17763.615. It seems to have to do with specifically putting the SP6 to sleep via flipping up the keyboard. If you sleep by Windows > Power > Sleep or pressing the power button or letting the SP6 go to sleep on its own, the SDB is correctly maintained. Another odd observation is that if you sleep via the 3 ways listed above but then flip up the keyboard, the SDB is cancelled.
I currently run a 64bit Windows 10 development box. I have old VB6 source that I have to unfortunately keep updated for the time being. For some reason all the sudden I noticed that one of the applications I have just built seemed to stay running in the background after the GUI was closed.
I started debugging the issue more and more until I found out that the only time it would seem to persistently stay open in the background after the GUI was closed was if I clicked the button on my form that would call the Common Dialog control to show the file open GUI. I only have to show the file open window and then hit cancel for this to happen.
This ONLY seems to happen on ONE of my dev machines (not the other). Every time I use that CD file open box I have to open task manager up and end the task. I also tried to make sure all forms were closed when my main form starts to Unload. Nothing seems to work or shed any clue on what the issue is. I have also double checked that the following files are now all the same coping them from the known working dev machine to my broken one and re-registering them.
COMDLG32.OCX
comdlg32.oca
comdlg32.dll
COMDLG32.DEP
Both machines are running the same exact OS Win10 Pro 64bit.
That does sound strange, getting different results on the two machines. Pragmatically, you can work around the problem (without actually understanding it) by making sure that you execute an End statement. (You can put it in the QueryUnload event to make sure it's hit if the user clicks the "X".)
I am trying to programmatically open the windows 7 on screen keyboard (osk.exe) from my program.
I found a good guide for this on this page and it works quite well when UAC is turned off.
When UAC is turned on, it is not opening the program at all however, and I can't find why. No UAC prompt is shown when opening the keyboard from the start menu, so it doesn't appear to need administrative privileges.
Is it just because the executable is located in the windows system folder, and if so, is there another way to launch a program that would work?
The error returned is 3, ERROR_PATH_NOT_FOUND, possibly because 'sysnative' path is not working with UAC enabled.
Trying to run "osk.exe" without path also fails, with an error "Could not start the On Screen Keyboard"
Finally, running "C:\Windows\system32\osk.exe" fails with error code 5: SE_ERR_ACCESSDENIED when I tried to use it with redirection turned off (as suggested in this question)
I tested the c++ code sample you refer to in your message. The routine started either from VS devenv or as a standalone exe did always show the on-screen keyboard under any available UAC mode. My OS: Windows 7 Ult. SP1 64-bit.
I am using Visio professional 2003. It was working fine. But now when I copy and paste any shapes it showing the error "Open clipboard failed". After that I am not able to change any properties or name.
When I try to close the window it is showing warning as "You cant quit visio program because a program is handling an event from visio. If VBA at break point, reset VBA, then quit"
Can anyone tell me what the problem is?
this has been a problem with Visio for 7 years and the last 3 versions of the product(Visio 2003 to Visio 2010).
The issue happens if you are running some other clipboard manager, like ditto or similar. The only thing you can do is use task manager to kill visio, then disable any clipboard manager you are using and restart visio.
It is working fine after i restarted the system.
I'd like to ring in that I had this issue when a Citrix session remoting to server 1 which was remoting to server 2 went into "triple lock": The screen saver in all three servers had kicked in. Ditto went crazy as did every app that I used the clipboard in.
Once I unlocked the sessions (which were lagging like crazy) everything went back to normal.
On my side the issue was coming from Citrix. Thx for pointing that out Vincent.
Visual Studio 2005 C++
Windows XP Pro
I have a sample application that I am testing, that links with boost libraries.
However, the program runs ok. However, when I try and stop the program by clicking the 'Stop Debugging' button. The program ends, but the console window remains open. So I have many of them, as during my testing I am starting and stopping the application.
Even when I try and close it by clicking the close button it has no affect. And it doesn't seem to appear under task manager when the program ends.
The only way I can close them if I reboot windows.
I am thinking it might be a thread that has not closed, and maybe that is keeping the console windows open.
Many thanks for any advice,
I have also seen this issue, I think it happens when a mutex or semaphore is still locked, or a thread hasn't cleanly exited. The only way I've found to prevent this is to make sure all mutexes/ semaphores/threads are cleaned up after before stopping the debugger.
Also it's interesting to note that this problem doesn't happen on Windows 7 or Linux. I have tried stopping the same program at the same places and the program always cleanly exits.
Good luck and happy coding!