Something went wrong on one of my last debug session with Google Apps Script (don't know what). Since then, I'm not able to run a debugger anymore. The debugger refuses to start.
When i checked the Execution Report/page I noticed all my debugging sessions are still running. I tried to terminate them by selecting the 3-dots menu on the right and the Terminate command (for every single process).
Apparently the process/execution was terminated, I even received a confirmation:
But, as I refresh the page, all the executions are still up and running.
I posted an issue on the Google IssueTracker, but so far no answer. Other people have posted the same issue, but so far nobody has received an answer from Google.
https://issuetracker.google.com/issues/177450621
P.S. I'm not using triggers.
Related
I was trying to debug a Python program using PyCharm's debugger and each time I resumed execution after hitting a breakpoint my program exited with an obscure error (this particular program is based on Twisted and the error was about not being able to stop an already stopped reactor). The program ran fine within the debugger as long as I didn't stop it with a breakpoint, and it ran fine outside the debugger.
This problem started occurring sometime in the last weeks/month, but in the past I have been able to debug this same program without issue.
It turned out that I just had a function call expression in the PyCharm debug pane that was getting evaluated whenever I hit a breakpoint and that function had a nasty side effect. It was left over from a debugging session several weeks ago related to a shutdown problem (so it kind of makes sense). I pulled a small amount of hair over this, and didn't find anything with google, before I noticed the problem. I hope someone else can learn from my mistake.
I'm creating a Windows event log-clearing software.
Whenever you clear logs from the command-line, there are always a few logs that can't be cleared, because either newer versions of Windows don't use the services those logs were meant for anymore, or they are important system logs that are almost always being written to.
However, when the Windows event utility tool finds out it can't clear those logs, it relays an error message to the user. And because I'm trying to make this Batch file into an actual software, I would rather not have a bunch of messy error messages on the screen, for the sake of the user experience.
The obvious answer to this problem would be to have the batch file start a separate background batch script to clear the logs, where the user wouldn't see any error messages, but modern-day anti-virus really don't like batch scripts, and flag them almost every time, so I can't do that.
I tried to instead create a powershell script (Much more trusted by anti-virus.) to clear the logs. But because of the nature of powershell, even if it runs completely in the background, without a console, it still relays error messages in the form of VBS XMessages.
If it's any useful, here's the two lines of code in the powershell script:
wevtutil el | Foreach-Object {wevtutil cl "$_"}
exit
And for those who are wondering, yes, I am clearing logs with administrative privileges.
I need one of the following:
Another way to clear Windows event logs, that doesn't show error messages, that I can integrate into the software I'm creating.
A way to forcefully clear those Windows event logs that normally can't be cleared.
A way to have a batch script run without anti-virus having a stroke.
A way to make the powershell script run completely in the background, without event displaying error messages.
To any who happened to stumble upon this question, the answer is in the comments section, as credit goes to #vonPryz, who mentioned that Clear–EventLog would work better than wevtutil, and it does.
I'm debugging plugins on Windows 7 and of course the plugin host (Cubase5.exe) occasionally crashes because of errors in the plugin. On XP or Vista, I could always restart it immediately and continue working. But on Windows 7, even though Cubase appears to close, it is still visible in Task Manager and I cannot kill it by any means. After a minute or two, it disappears by itself. In the mean time, I can't work because the plugin DLL is still locked by the process.
Does anyone know why this happens on Windows 7? I've already tried disabling Automatic Error Reporting but that didn't help. I've tried attaching cdb to Cubase, but I get:
Cannot debug pid 5252, NTSTATUS 0xC0000001
"{Operation Failed} The requested operation was unsuccessful."
Debuggee initialization failed, NTSTATUS 0xC0000001
"{Operation Failed} The requested operation was unsuccessful."
I tried following the instructions here but it appears this is only possible if I connect a second machine to my computer to debug it remotely.
I finally found the solution, using this article:
http://blogs.technet.com/b/markrussinovich/archive/2005/08/17/unkillable-processes.aspx
This required installing the Windows Debugging Tools for Windows (nice name) and LiveKd, but by following the steps outlined I was able to track which driver was causing the process to hang: it turned out to be the 64-bit driver for the M-Audio Oxygen 8 V2 controller I'm using. Unfortunately no driver update is available.
Anyway, if anyone encounters a similar problem, this is the way to solve it.
Have you tried Process Explorer by Mark Russinovich? It is really useful for "killing":)
If you have error reporting enabled, it's possible that werfault.exe has Cubase open to write a minidump for crash reporting purposes.
This is just a stab in the dark but it might be your problem.
One thing you can try is to check with Process Monitor what Cubase is doing. Set a filter so that everything with a process name containing "cubase" will be recorded. It could be that you are facing some timeout issue when Cubase wants to exit.
you can end the process the service is running under. You can find this process by going to the Services tab of the Task Manager, right-clicking, and selecting Go To Process(you need to click the Show processes from all users button.). Note that one process may host multiple services (especially if it's svchost.exe), and ending the process will kill all those services. Also, this is an unclean exit, and may cause data corruption depending on what the service(s) was doing when you killed it.
Depending on which specific service you are trying to stop, there may be a cleaner way to simulate failure.
I'd like to detect when someone terminates a suspended debugged process without informing the debugger. (For example, get to a breakpoint in a console app, and close the app's console window.) The process goes into a zombie-like state and cannot be interacted with further until the debugger releases its hold.
This state appears to set the PROCESS_EXTENDED_BASIC_INFORMATION::IsProcessDeleting flag when gathering information on the process via NtQueryInformationProcess, but both the flag, structure, and function are effectively undocumented and marked "do not use" on MSDN.
Is testing this flag reliable? Is there a better, "official" API I can use?
(Yes, I know IsProcessDeleting is also set when the process is (surprise, surprise) shutting down normally. This is not a problem from my perspective.)
Nope, not that I can see. NtQueryInformationProcess isn't going away anytime soon though, if that function was removed hundreds of apps would be broken by it.
An application is hanging occasionally, and I would like to see the dump at the time to figure it out. I had written an application that the user can run to automatically create a dump that I can look at. However I can't seem to get the users to remember to run it when it hangs, no matter what I try. They always end up closing the program, which invokes Windows Error Reporting.
WER will create dumps in the temp directory, but unfortunately they are deleted as soon as the dialog for sending the info to Microsoft or not is closed.
Becoming an ISV and getting this info from Microsoft's error reporting servers is one solution.. but not one that is realistic at the moment.
I can't imagine that I am the only one faced with this issue. The software is used concurrently by dozens upon dozens of staff, so reaching them all and getting them to run an application or not click close on that dialog until running some other application or etc has not been working out.
The app is running on Windows Server 2003. Too bad, since I know Server 2008 has some LocalDumps options that will let me retain them.
Any ideas for somehow keeping these dumps around so I can analyze them? The obstacle is the user, in the sense that I've accepted to their stubbornness and do not expect them to run any other application or do anything special.
Thanks for any advice!
You could opt for an automatic solution. I believe there're multiple options at your disposal for detecting if you're hung.
One would be the use of SendMessageTimeout (also pay attention to SMTO_ABORTIFHUNG as one of the fuFlags values) from a separate thread in your app. Once you have determined the main thread is not responding you can save a dump file wherever you want.
There's also a IsHungAppWindow() (user32.dll) available since w2k.