When there is a GUI program not behaving as I expect it to in Linux I run it from the terminal so that I can see what errors are happening in the background, this helps in configuring the system and figuring out dependencies when the problem is not from the program but rather the system. This is especially helpful when the program doesn't give any feedback to the user in the GUI.
Is there a way to do the same thing in Windows?
In general, Windows programs are much less well defined in how they run, and there tends to be a much wider variety in the quality of the application, especially in regards to logging and debugging.
Most (all?) windows applications can be run from the command line. You just have to find where the executable is located, and then run it. Looking at the path in an application shortcut can be helpful for this.
Some applications have command line switches that do various things, but many don't. If there is documentation for the particular program, you may want to check there.
Some well behaved windows programs will log to the System log. Depending on your access level and the version of Windows you are running, the System log can give you some good information about things that might be going wrong with the program, such as file permissions, etc.
In general, however, no, there is no way to get error output from a program if it doesn't already output it.
Related
Hey I'm working on Windows in an office environment with an uncooperative MS Access database.
We're experiencing crashes and hangs with no error messages. I am used to a *nix environment where I can launch a program from the terminal and get stdout/stderr redouts making it much easier to see what was running just before it crashed the computer...
Experimenting with launching from windows' cmd hasn't yielded anything similar (not dug too far into powershell because I'm not allowed admin privileges on this machine ¬_¬). Does anyone know a way I can dig beyond a hanging GUI and get at a readout of logs, or preferably see messages piped to the command-line as the program whurrs away?
Worth noting I'm in a restrictive IT environment where I cannot install any additional tools, so whilst I'll be interested to hear about the wonder program that will solve my problems I'll be unable to install anything that isn't built in to Windows.
There is no such thing in MS Access.
You will have to write your own error handling that will write errors to a log table or log file. Of course, this will only work until your application halts.
The behaviour you describe is not normal, so the cause for your trouble may very well be anything but MS Access itself.
So i recently got myself into a sticky situation, it seems like windows 'forgot' about a program I had installed (some drives changed letters / not really sure what happened).. I could find files that it created, but in 'Programs' and 'Add/Remove Programs' it is not there.
Also, when I use the 'programs' installer, it says it cant install because it exists already (to some extent), and I can un-install because windows doesn't know it exists.
BUT! I have an executable of the 'program' that works.
So I am wondering what the difference is between an executable, and what windows considers to be, and keeps track of, a 'program'.
This is definitely the kind of program that would show up in 'add/remove programs', as I have several other very similar ones from the same company that show up there, and I know it used to show up there.
I am not looking for wikipedia answers, I am interested in what exactly a 'program' is. What are the necessary pieces that make up a 'program' as far as windows is concerned?
For a program to show up in "add/remove programs", it needs to be installed. Typically, this is done through an installer that takes care of registering the program with windows and modifies the environment so that the program functions properly.
It may modify the registry to store user preferences for example...
When you have just an executable, it's not necessarily installed. It may be standalone.
Some programs don't absolutely need to be installed even if it's the canonical way to add a program in the Windows system. That's why it may work.
Another executable may fail because it relies on modifying the state of the system to work properly.
I hope it helps :)
I've got a Windows application (written in C, compiled with MSVC Express edition, 32-bit mode), which has two main modes of operation:
Windowed mode -- create a window, and draw stuff in it (namely, a fractal).
Benchmark mode -- when run with --benchmark as an argument, don't make a window but just print some benchmark statistics to stdout.
During development I've compiled as a Console app, and used SDL to create the window and perform other GUI functions. So benchmark mode runs fine (no window is created), and graphical mode just has a lingering console window.
However for my release compilation I've enabled the Windows subsystem instead of Console. (As explained in this question). This works great except I've suddenly discovered I can't run benchmarks any more. :o
I'm just wondering, is there a way for an application to choose at run time (e.g. based on the command line it's given) which kind of subsystem behaviour to use?
I've done some experimentation with EXE files in Windows (explorer, notepad, winword) and none of them seem to print anything to the console when run with an argument like "/?" (which most Windows console apps support). So it doesn't look like it, but I thought it's worth asking here in case there's a special trick.
Update. It looks like, no, you can't. Thanks for the answers guys.
Additional academic question. Does this mean that the subsystem choice is marked in the EXE header, and it's the operating system that examines this and sets up the Window or connects it to the console it's run from? I don't know much about EXE loading, but I would be curious to learn a few details here.
Conclusion. I think there are four good solutions (plus two semi-solutions, making five total :p) to choose from:
Use the console subsystem, but use FreeConsole when running in GUI mode.
Use the windows system, and use AllocConsole when running in benchmark mode. Not perfect if fractal.exe is run from an existing console, so I'll count this as half a solution ;-).
Just have one executable for each subsystem, fractal.exe and fractalgui.exe.
Have two (or more) executables, one of which does the work and passes it to the other to be displayed on the console or in a Window as appropriate. Needs some thought on how to divide the programs and how to communicate between them.
Another half-solution: have fractalgui.exe print the benchmark to standard out, and pipe that to a utility that will simply print it.
I haven't yet chosen, but I'm leaning towards #3.
Thanks to Matteo and smerlin for the ideas!
There is no way a application can choose her subsystem at runtime (well there are some really ugly workarounds, but those are full of quirks).
Then general solution for this problem is to have a console application, which starts your gui application if necessary
For your benchmark case, it would just print your benchmark statistics.
example setup:
- fractalgui.exe (subsystem: windows)
- fractal.exe (subsystem: console)
* the shortcut on the user desktop links to your fractalgui.exe
* if the user starts fractal.exe from the console, fractal exe starts fractalgui.exe
* if the user starts fractal.exe --benchmark, it either does the benchmark itself (if its possible to add this benchmark logic to another executable) and prints the information directly to console, or - if thats not possible - it will need to start fractalgui.exe --nogui --benchmark. The tricky case here is to get your output from fractalgui.exe to fractal.exe, so you can print it on the appropriate console. There are several ways to do this, e.g. named pipes (there are ways to start fractalgui.exe in a way, that you can just use stdout / cout there, and the data will be piped to the stdout of fractal.exe, but i dont recall how excactly this works anymore (edit: maybe this works)). The easiest way would be to start fractalgui.exe --nogui --benchmark > mylogfile and then print mylogfile after fractalgui.exe finished (since stdout/cout of fractalgui.exe will work if the output is redirected to a file), however you wont get "live" output, since all the output will be printed on the console when fractalgui.exe is already finished.
To add to #smerlin's answer, the other oft-seen method (cited into the articles I linked inside the comment) is to mark your application as a console application, but free the console (using FreeConsole) when you determine that you don't need it.
This is how ildasm does it, but it has the disadvantage of flashing the console for a brief moment between the start of the application and the call to FreeConsole.
Additional academic question. Does this mean that the subsystem choice is marked in the EXE header, and it's the operating system that examines this and sets up the Window or connects it to the console it's run from? I don't know much about EXE loading, but I would be curious to learn a few details here.
Yes, the loader checks the PE header and sets up everything according to the subsystem specified here.
Contrast with the *NIX approach: no executable is "special", and everyone has a working stdin/stdout/stderr; applications that want to display something will call the appropriate functions of Xlib. The drawback is that GUI applications have no clue if the application you are starting normally uses the console, so the system has to ask if you want to spawn also a terminal emulator or to discard the standard streams and just wait for it to spawn a window (obviously shortcuts store this information).
I described a technique for achieving this in my question here.
Matteo already mentioned the .com trick, but that's only part of a viable solution.
I need to find out exactly what files/directories a Lua program uses so I can try to only pack what it needs into a ZIP file, and come up with a simple way to deploy this script.
I used SysInternals' Process Monitor, but I'm surprised by the small amount of information it returned while it watched the program (For Lua users out there, it's wsapi.exe, which is the launcher for the light-weight Xavante web server).
Does someone know of a good Windows application that can completely monitor what a program does, eg. something like a live version of the venerable PCMag's InCtrl5.
Thank you.
Process monitor will catch everything. If it's not catching the action then it must be happening in a different process. Try filtering based on the files you expect to be used rather than the process you expect it to happen in.
I have a multi-threaded Windows application that occasionally deadlocks. Inevitably this happens on a customer system and not when the software is in test. What is the easiest way of getting a Windows Minidump of the current state of the application? If it could also terminate the application so the user can restart it and continue using the system that would be great.
In Vista you can create a dump file directly from task manager. Right click on a process in the processes tab and choose 'create dump file'.
Prior to Vista I prefer the ntsd route, since although it is not totally user friendly it works without the user installing any other software and the instructions are actually fairly easy to follow.
See the Microsoft support article How to use ADPlus to troubleshoot "hangs" and "crashes", as well as the helpful blog post Debugging Production Applications using ADPlus.
Both of these articles are about "ADPlus", a VBScript tool supplied with Debugging Tools for Windows that can be used to generate minidumps from a production environment (which can later be loaded up with WinDbg on your development machine). ADPlus has a lot of functionality and a lot of options, so it may take some reading, experimentation, and practice to find the best way to use it in your environment.
I know how to achieve this. It's just my technique is a bit clunky. All Windows 2000 and later systems have a basic command line debugger as part of the default install called NTSD. What I do at the moment is run:
ntsd -pn MyApp.exe
When the debugger console appears I can then type the following into the debugger console:
.dump c:\my-deadlock.mdmp
.kill
What I'm looking for is something that's a little bit cleaner and easier to put in an email to customers to just run. I've seen it alluded to somewhere (that google can't find for now) that you can use drwtsn32.exe to extract a crash dump and terminate an application.
Edit: It is possible to streamline the command somewhat:
ntsd -pn MyApp.exe -c ".dump c:\my-deadlock.mdmp; .kill"
The command .detach can be given if the process has not terminally hung (e.g. a long network timeout) and you want the process to keep going.