I've ran into a few cases where powershell ISE will freeze when you try to kill a process with Ctrl+C. I can still move my cursor around the console but the status is stuck on "Stopping".
This has happened for several commands but one particular command I've noticed this consistently happening for is
mvn jasmine:bdd
This command runs a maven plugin which starts a jetty server. I can stop this with Ctrl+C from Powershell Console but not from Powershell ISE. Could this be related to the fact that Powershell ISE can't run interactive commands?
Right now my workaround is to just "start" maven in another process. Anyone else run into a similar problem?
Thanks
I opened case for Powershell team while referencing this issue.
https://github.com/PowerShell/PowerShell/issues/7970
Seems like recommended way is to use VS Code with Powershell.
Also this can help https://learn.microsoft.com/en-us/powershell/scripting/core-powershell/vscode/using-vscode?view=powershell-6
You may need to explicitly write the script to capture Ctrl-C as input. Found an circa 2014 post on Technet that seems to address a very similar phenomenon. Cannot speak the validity of the 'answer', but one of the links in the thread will take you down a bit of a rabbit-hole of other links with possible workarounds.
Related
I used Msys1 for many years and was used to CTRL+C for killing processes that I start within my shell.
After updating from Msys1 to Msys2 CTRL+C does not work any more.
For example: I start "make" press CTRL+C. Shell prompts to finished and enables typing more commands, but make.exe is still running+working.
Result of my analysis:
In Msys1: shell.exe(12345) starts make.exe(23456) and make.exe(23456) has the information, that its parent is (12345).
In Msys2: shell.exe(12345) starts make.exe(23456) and make.exe(23456) has the information, that its parent is the (34567), which is not alive anymore. So I guess Msys2 uses an additional process for starting subprocesses.
I tried bash.exe, shell.exe, mintty.exe,... all seems to have the same problems.
Content I found searching
:
This ticket just focuses on missing signal types -> I don't care about that.
https://sourceforge.net/p/msys2/tickets/135/
The issue in this mailing list seems to be near my problem, but I do not understand what I should change, or if the change can only be made within the msys2 implementation. (What is CREATE_NEW_PROCESS_GROUP? and how to change it):
https://www.cygwin.com/ml/cygwin/2012-08/msg00062.html
Kindest regards
Luke
It looks like mintty provides the default terminal for MSYS2 (note that this is different from the shell that is run within). If so, then the "Ctrl+C kills native (e.g. MSYS2 compiled) programs abruptly rather than sending a catchable signal" problem is the same one as described over on https://superuser.com/questions/606201/how-to-politely-kill-windows-process-from-cygwin and the MSYS2 wiki porting FAQ.
If what you're attempting works when you are using Windows' default terminal (e.g. when using cmd.exe from the start menu) then this is the issue you're seeing.
It is in fact suggested in the other answer but you can just run each program by winpty.exe which will make CTRL-C working again.
I've run into an issue with a program I created using Livecode, and now I'm looking for some help from the experts. My Google-fu is strong, yet the answer eludes me...
So here's the deal. I made a very basic note-taking program for Windows only, using very noob skills. I've been using it daily for work for the past month at least. It functions exactly as it should, except for these few things that don't make sense:
When loading the program, it takes 25-30 seconds to load. Not convenient considering it's pretty basic; one button and 5-6 text input fields, with the same number of label fields. And one background. The button just clears the text input fields.
I started to notice a problem when I went to create a batch file to load all my work programs. When the program is loaded thru Command Prompt, if I close CMD it will close the program too. I tried the same using Powershell, and it still closes as soon as the Powershell window closes. Really really strange.
I managed to find another standalone program made with Livecode, downloaded it and tested the CMD command to see if the same thing happened. It didn't, that program loaded instantly and it is ENORMOUS. It also didn't close when I closed the CMD window. I even tried this: opened my program and the downloaded program using the same CMD session, and when I closed CMD, my program closed but the downloaded one did not.
Then, I downloaded the source code for the program that was working correctly. I created a standalone for it, and tried to open that. It acts the same way as my note program does.
I don't get it. It's got to be something in my Standalone Application Settings considering what happened in the last step I mentioned, and I've been over and over those settings for hours, but I just don't have the knowledge of LC to know what to look for. I've scoured the web looking for answers to this, but it seems to be just me having this issue (story of my life, lol).
I'll be happy to post any codes, scripts, or files needed, please let me know. I just don't know which things to post =P
Any suggestions are very much appreciated!! Thank you. =)
If you call the program from the prompt directly, e.g. using
C:\program files (x86)\your_standalone.exe
the app is treated as a command line app. I have also noticed that a LiveCode app can sometimes close if the invoking command line prompt is closed, while it may sometimes continue to run. Perhaps the handling of the relaunch message has to do with it, since this message basically handles commands from the command line.
If you want the command line process to finish independently from the invoked LiveCode application, you can use the start command:
start "" "C:\program files (x86)\your_standalone.exe"
don't have enough info to be able to tell what your issue is. But that much of a delay is not usual for LiveCode apps so something is definitely wrong. How long does your app take to load if you open the stackfile in the IDE?
Not sure what StackOverflow allows but if you could upload your scripts and if possible stackfile that will give us more to go on
This has nothing to do with Windows, Batchfiles, or CMD.
CMD can workaround your problem, if it's a GUI program. See Start command, and read the help as it explains the starting behaviour of CMD and CMD's Start.
Explorer has different rules. Anything else that starts programs call CreateProcessExW which has it's own rules.
I am doing some analysis work on some software we are running where I work. The software seems to have memory issues some where along the line which are proving difficult to track down. We have decided to use Sysinternals VMMap to track the memory being used by the software.
We have VMMap exporting the usage every 20 seconds using Windows scheduler to launch a batch script which pulls back the target process PID and launches VMMap with it. The process runs for a while, output appearing the out directory but after a while it stops. Windows scheduler reports the job ran fine and will start another instance when the trigger is meant, once again with no output.
After a bit of investigation it looks like VMMap is failing to open the process and is trying to report an error through its GUI. Since we are running in batch, we cannot see this error to dismiss it. This is causing numerous process' to be spawned but not actually doing anything.
Has anyone come across this issue when using VMMap, or know of anything that may help? I am thinking there may be some flag I can pass which suppresses messages or maybe some way I can handle it in the batch but Google hasn't helped nor has the Sysinternals forum. Any help would be really appreciated.
VMMap is a GUI tool, so trying to capture its output in an automated way will be difficult. Instead, try using another SysInternals tool, Handle, that captures a lot of the same information, but exports/reports on it in command line, where it can be captured much easier. Alternatively, don't run the output in an auto-repeating way when using VMMap, but instead have your script somehow detect the error or missing expected results/data and stop so the GUI output can be examined.
All Sysinternals tools do pop up a consent dialog for the first time they are started on a new machine to accept their license. I think you did deploy the tool to a production machine and it was trying to show the consent dialog but nobody did press ok.
They do basically create a registry key on the machine which you can fake if you need a fully automated deployement or you can start in once on the target machine for the user in question.
I tried to wrap a little command in a batchfile to prevent me from typing it the whole time. But the result was a mess! I'm ended up with thousands of cmd processes and was unable to stop it with CTRL+C
The command was quite simple START iisreset
System Win7 64bit
Why is that happening?
EDIT:
With some help and additional tests I can now say that the Batch command START within a *.cmd file cause that mess. It opens a new commandwindow with every window until it crashes. Maybe you have luck and hit CTRL-C exactly the right time, but that really has to be luck. Anyway I will not use this command in future and it also seems not to be applicable to all machines. (Read the comments for full history of this)
It works OK on Windows 7 pro, 64 bit, but based on the other stuff you've tried, it looks like it might be a bug... You could try raising a bug report
(although that seems like a non-trivial exercise).
We are using VS 2008 Team System with the automated test suite, and upon running tests the test host "randomly" locks up. I actually have to kill the VSTestHost process and re-run the tests to get something to happen, otherwise all tests sit in a "pending" state.
Has anyone experience similar behavior and know of a fix? We have 3 developers here experiencing the same behavior.
This may be related to an obscure bug that causes unit tests to hang unless the computer name is UPPERCASE. Crazy, I know - but I had this problem and the fix worked for me.
Bug report on MS Connect
Workaround on MS Connect
TFS Blog Article about this issue
HowTo edit the registry to change your computer name
The easiest approach is to tweak the registry. You need to edit two keys:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ActiveComputerName
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName
Change value ComputerName to be upper case in both keys, and restart. Tests then magically work.
When you say lock up, do you mean VS is actually hung, or do the tests not run?
The easiest way to track down what is going on would be to look at a dump of the hung process. If you are on Vista, just right-click on the process and choose to create a memory dump. If you are on Windows XP, and don't have the Debugging Tools for Windows installed, you can get a memory dump using ntsd.exe. You'll need the process ID, which you can get from Task Manager by adding the PID column to the Processes tab display.
Once you have that, run the following commands:
ntsd -p <PID>
.dump C:\mydump.dmp
You can then either inspect that dump using WinDBG and SOS or if you can post the dump somewhere I'd be happy to take a look at it.
In any case, you'll want to likely take two dumps about a minute apart. That way if you do things like !runaway you can see which threads are working which will help you track down why it is hanging.
One other question - are you on VS2008 SP1?
I would try running the tests from the command line using MSTest.exe. This might help isolate the problem to Visual Studio, and at least give you some method of running the tests successfully.