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".)
Related
I created a binary at some Windows 10 machine, and trying to start it in other machines, but keep getting the shown screen every time I launch the app, if I clicked "No" the app will start, but this is annoying and keep the end user confused, any thought how to avoid this?
I found the solution, it is Windows protection issue rather than Binary issue, where windows trying to protect from unknown binaries, the solution is very simple:
Rihgt click the app
Slect Properties
Check the Unlock
Click Apply
Click OK
Relatively new to intermediate level Windows user here. I recently installed a game which kept restarting (automatically) every few seconds even after I closed it every few seconds. Windows (I use Windows 8.1) kept trying to open the .exe even after I uninstalled. I tried deleting a couple of registry entries of it (I guess I deleted a dll registry related to it)
After deleting a couple of registry entries
but it still keeps trying to open it. What can I do about it?
These guys keep coming up as I close them
Currently doing a CS course. This is my first question on stack overflow!
EDIT: This window keeps popping up every few seconds. (I have uninstalled it)This one. The game is Battlezone(1998) from Microsoft which itself is legit. I found it on a really old CD which I found in my house recently and I just installed it. It is clear on Avast Antivirus. Nothing suspicious there in Task Manager or in Startup
Try using the Taskmanager to stop any process that is related to that programm.
If you have uninstalled it and the programm still starts it probably is still installed -> the .exe file hides somewhere.
Try find and delete it manually.
You can check if you have a system tray icon as well, some programms don't close if you close them but minimize into a system tray icon. These can often be closed using right click -> close.
Does the programm start automatically after pc start? -> check your autostart folder and the autostart tab of your taskmanager and remove it.
Anymore stuff you can provide us with? -> which game, screenshots, you sure it's not maleware?
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 have a Surfacebook (first generation) running Windows 10 Enterprise and joined to my company's active directory domain. I'm not sure what happened (as best I can tell now updates were installed nor were any GPO applied), but I woke up to a machine that seems to have several core setting reset. All of my apps that were pinned to my Taskbar and Start Menu were gone, and my app auth tokens were reset, and the two powershell related shortcuts off the context menu of the Start button were no longer mapped to .lnk' files. I'm trying to get these powershell menu items working again and I'm having no luck.
Doing this:
Fails with:
This file was indeed gone. I don't know what removed this, but I recreated it:
But still it fails. I've checked the permissions, I own the directory and .lnk. I've rebooted and still it didn't work. Anyone know how to get this back to functional? And I would love to have a clue as to what might have caused all this to go haywire.
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"