This question already has an answer here:
Closed 11 years ago.
Possible Duplicate:
Windows Program: How to snoop on command line arguments?
I am working under Windows XP.
I've been given some third-party software that spawns several processes when launched. I've been tasked with writing a replacement for this software, though I will need to keep one of its proceeses (a "communication server" that passes / receives messages to / from identical "communication servers" on other networked machines). One small part of this process is learning to start the "communication server" directly. If I just start it with no arguments from the command line, it immediately dies. I'm thinking it needs some arguments. So, all my question boils down to is...
Is it possible, for any arbitrary process, to see what arguments it was started with? If so, how may I do so?
I tried attaching Visual Studio 2010, but there's no .pdb, so I got nothing. Unfortunately, I do not know what language this "communication server" is written in. So, it was really a longshot. (I wasn't sure if doing so would give me a way to find the arguments anyway, but I thought it was worth a try.)
Thanks,
Dave
P.S. Sorry for the poor choice of tags. This is a tough one to categorize...
Process Explorer displays them. Right click on a process in the list, then Properties... -> Image -> Command line
It's not 100% reliable since the process can overwrite the buffer containing the command line, but usually it works.
Process explorer will allow you to see the command line arguments for a given running process :)
You don't need the PDB for the app itself. Windows DLLs have PDB's; put a breakpoint on CreateProcess and variants like ShellExecute / CreateProcessAsUser.
Related
I want to make command line VB6 application which prints its result to the command prompt (similar as printf in C). However, none of the found solutions does not work for me.
I have VB6 SP6, Windows 7 x64.
I tried
How to write to a debug console in VB6?
to accomodate this, but in this line
Public SIn As Scripting.TextStream
compiler returns an error: User-defined type not defined
Why this is not workin? Is there a way to do it?
I would prefer API solution (system independent).
The best solution is Karl E. Peterson's code at http://vb.mvps.org/samples/Console/ which has complete source, interactive debugging, several examples and many other great features. No need for scripting.
But if you make an EXE file (and sure you would!), it is absolutely necessary to fix resulting EXE (explanation and manual is on the same Peterson's page), i.e. to set PE bit in EXE header.
Otherwise, if there in EXE is any input waiting, EXE will enter an infinite loop and will never return (but in command-prompt it looks like finished, because prompt is displayed). If you try to start EXE more times, you can see these never-ending processes populating in Task Manager/Processes).
I have little previous experience with Windows (for programming, anyway), but recognizing that Windows has an enormous market share, I am trying to support it in my programs (even though they are just for fun, I like to pretend they're big projects). I have written a tiny shell with minimal (and when I say minimal, I mean minimal) features.
I am trying to port it to Windows and would like to use it independently from cmd.exe in a Win32 Console window (meaning the shell part of cmd.exe isn't running at all, but the window used for it shows). I have already done most of the other porting stuff such as build system (CMake) and changing appropriate Unix syscalls to Windows ones in a #define. I have done a little research and found little on this topic, however. I know it is possible because I've seen it done with Bash. Visual Studio also used to do it when I ran a program in its GUI.
Reference article I got some of this info from: https://en.wikipedia.org/wiki/Win32_console
Note: What I mean is when you click on it and it opens it without running cmd in its own little console window. Or when you type it into cmd it opens in a separate window that isn't running cmd. I am assuming cmd.exe and the console window it runs in are two separate things, but if I am wrong, please let me know. :)
This question is inspired by https://askubuntu.com/questions/111144/are-terminal-and-shell-the-same and a similar question where I got that Wikipedia link. Someone said that the console window and the shell were separate. I was writing my own shell so I started to wonder how to make mine independent of the default one.
The Win32 Console and cmd.exe are two different things. Windows automatically opens a console window when a program that needs one is started. It decides whether do to so by switches hard-wired into the executable. This window will be running said program. If the program that started the process is running in a console window, the two programs will share that console window.
As Noodles said, it really is that simple. You just start it. Double-clicking on it will do it. The CreateProcess() function with CREATE_NEW_CONSOLE passed to it will do it. Running the program from cmd.exe with
start <command>
will do it.
There is also a family of functions in the Windows API, called FreeConsole() and AllocConsole() that will free a program from its current console and create a new console for it, respectively.
Reference link (given by Noodles): https://msdn.microsoft.com/en-us/library/windows/desktop/ms682010(v=vs.85).aspx
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.
This question already has answers here:
Debugging with command-line parameters in Visual Studio
(13 answers)
Closed 8 years ago.
I am debugging an application someone else wrote which runs as a Windows Service unless it is started from the Console and passed parameters. I would like to start this program from the Console, including some parameters, and then step into the debugger. I'm not sure how to do this since before I execute the command to start it, there is no process to attach to, and once I execute the command, it's too late to catch it (errors begin almost instantly). I'm trying to figure out if there's a way in Visual Studio to set up the debugger to attach to a process before it's actually running (or perhaps something effectively similar, given the description of my problem).
I have a breakpoint on the very first line of Program.Main and I'm essentially trying to figure out how I can launch the application from the Command Prompt and then immediately hit my breakpoint. Is this even possible?
I'm running VS 2013 on Windows Server 2012 Datacenter, by the way.
I think that you don't need to run this program from console - just run (start debugging) it with parameters. Here there is similar question, it should solve you problem. Note that if for some reason my advice is not a good solution for you, you can use solution from second answer (from link) - it's exactly what you are asking for.
this is not yet another "I need a console in my GUI app" that has been discussed quite frequently. My situation differs from that.
I have a Windows GUI application, that is run from a command line. Now if you pass wrong parameters to this application, I do not want a popup to appear stating the possible switches, but I want that printed into the console that spawned my process.
I got that far that I can print into the console (call to AttachConsole(...) for parent process) but the problem is my application is not "blocking". As soon as I start it, the command prompt returns, and all output is written into this window (see attached image for illustration).
I played around a bit, created a console app, ran it, and see there, it "blocks", the prompt only re-appears after the app has terminated. Switching my GUI app to /SUBSYSTEM:Console causes strange errors (MSVCRTD.lib(crtexe.obj) : error LNK2019: nonresolved external Symbol "_main" in function "___tmainCRTStartup".)
I have seen the pipe approach with an ".exe" and a ".com" file approach from MSDEV but I find it horrible. Is there a way to solve this prettier?
This is not behaviour that you can change by modifying your application (aside from re-labelling it as already discussed). The command interpreter looks at the subsystem that an executable is labelled with, and decides whether to wait for the application to terminate accordingly. If the executable is labelled as having a GUI, then the command interpreter doesn't wait for it to terminate.
In some command interpreters this is configurable. In JP Software's TCC/LE, for example, one can configure the command interpreter to always wait for applications to terminate, even GUI ones. In Microsoft's CMD, this is not configurable behaviour, however. The Microsoft answer is to use the START command with the /WAIT option.
Once again: This is not the behaviour of your application. There is, apart from relabelling as a TUI program, no programmatic way involving your code to change this.
Maybe write a console-based wrapper app that checks the parameters, prints the error message on bad parameters, and calls/starts up the actual program when the parameters are correct?