I was wondering if it was even possible with RUBY to watch other applications and if a certain application is below a memory threshold it kills it and starts it again.
Operating System would be Windows 7+
Things I need to be able to do:
Monitor Memory
Determine between different processes
Kill Processes
Start new process (bat script or powershell)
Start monitoring again
The watched application running would run high memory when it is working and that is good. If it goes below 1gb I want this application to kill it. Of course when it restarts it would give a grace period for it to load the RAM.
I was going to use the Shoes gui framework to make something nice to wrap around it. It would be theoretically nice to have some sort of auto detection if the application is running.
If this is possible, but requires Gem you think may help I would like to hear about them.
I found Usagewatch Gem seems to be headed the right way, but from a glance at the documentation it is general and I need to be specific about which process I am watching.
If this question is not appropriate here please let me know via a comment and I will remove it and/or move it to a proper place for this type of question to be asked.
I appreciate your time and effort into helping me with this endeavor.
Thank You
I would suggest using the win32 gem. Than start by looking through the Win32 Api documentation. This will give you the most flexible solution and will give you the whole system programming power for Windows. My advice is to make some wrapper functions about the things connected with Windows you need and use them that way, so if you find a more appriete solution you can switch to it easily.
Related
( Hi, everyone. I'm very new to Windows programming, so I apologize in advance if this has already been asked and I just didn't know what to search for, but this problem has been driving me crazy and I know someone could probably answer this really easily. )
My company has an application that runs as a service in Windows 7. I have been tasked with writing code to change display settings, but I apparently cannot do this from a system service. I created a small executable that changes the color depth to 8bpp in about 5-10 lines of code, but when I place this code in my application, it returns success yet does not actually succeed (nothing changes).
Without a commanding knowledge of how Windows programming works, I have managed to try a MILLION different things to get it to work but with no avail. Can somebody PLEASE help me find what I need to do to make this code function?
On Vista and upwards services run in a different session (session 0) and are isolated from the interactive desktop(s). This means that code that you run from the service is simply unable to make the changes you want. The obvious conclusion is that you need to run code in the interactive desktop.
Now you can do this, but it's not exactly easy to achieve. What you will need to do is arrange for your service to launch an process that runs on the interactive desktop: Launching an interactive process from Windows Service in Windows Vista and later. That process, rather than the service, is what will have to make the changes.
Whilst it is possible to achieve what you want, I think you should regard the difficulties involved as a signal to review whether or not your proposed approach is the best solution to whatever your underlying problem is.
I am designing a networked embedded application, that can span multiple machines. The applications is divided between these machines.
Now, when it comes to exerting explicit control on this system, there are two options:
(1). A nicely managed strategy in which the application nicely releases resources, and goes out. No memory leaks, and it all looks good.
(2). I am facing criticism from people on the managed approach: Why is it not just as good to kill the process, in each machine separately? My only defence is that it is not nice, and may leave the system in an unstable state. This argument does not cut with them.
Can anyone please help? I know that kill is not the best way, but why? Also, are there some references? I will need to include them in my work.
Sorry, this problem may be discusses ad nauseam, but I cant get any "references" to support my point.
Thanks for any help.
Here's a few things I did find regarding cleanup of resources with killing the process
One example
Another Example
Socket Example
I have an application, which displays me some data. I need to attach to this app's process, find the data I need in memory (one single number, actually), and save it somewhere. This application doesn't seem to use standard windows controls, so things aren't going to be as simple as reading controls data using AutoIt or something similar.
Currently I'm a self-learner database guy and have quite shallow knowledge about windows apps debugging. Not even sure if I asked my question correctly enough.
So, can you give me some starter guidelines about, say, what should I read first, and general directions I should work on?
Thanks.
To read memory of other application you need to open the process with respect of OpenProcess with at least PROCESS_VM_READ access rights and then use ReadProcessMemory to read any memory address from the process. If you are an administrator or have debug privilege you will be able to open any process with maximal access rights, you need only to enable SeDebugPrivilege before (see for example http://support.microsoft.com/kb/131065).
If you don't know a much about the memory of the destination process you can just enumerate the memory blocks with respect of VirtualQueryEx (see How does one use VirtualAllocEx do make room for a code cave? as an example where I examine the program code. The program data you can examine in the same way).
The most practical problem which I see is that you ask your question in too general way. If you explain more what kind of the data you are looking for I could probably suggest you a better way. For example if you could see the data somewhere you could examine the corresponding windows and controls with respect of Spy++ (a part of Visual Studio Tools). The most important are the class of windows (or controls) and the messages which will be send at the moment when the most interesting window are displayed. You can also use Process Monitor to trace all file and registry access at the time when the windows with the interesting information will be displayed. At least at the beginning you should examine the memory of the process with ReadProcessMemory at the moment when the data which you are looking for are displayed on the window.
If you will have no success in your investigations I'd recommend you to insert in your question more information.
My primary advice is: try to find any other method of integration than this. Even if you succeed, you'll be hostage to any kinds of changes in the target process, and possibly in the Windows O/S. What you are describing is behaviour most virus scanners should flag and hinder: if not now, then in the future.
That said, you can take a look at DLL injection. However, it sounds as if you're going to have to debug the heck out of the target process at the disassembly level: otherwise, how are you going to know what memory address to read?
I used to know the windows debugging API but it's long lost memory. How about using ollydbg:
http://www.ollydbg.de/
And controlling that with both ollydbg script and autoit?
Sounds interesting... but very difficult. Since you say this is a 'one-off', what about something like this instead?
Take a screenshot of this application.
Run the screenshot through an OCR program
If you are able to read the text you are looking for in a predictable way, you're halfway there!
So now if you can read a OCR'd screenshot of your application, it is a simple matter of writing a program that does the following:
Scripts the steps to get the data on the screen
Creates a screenshot of the data in question
Runs it through an OCR program like Microsoft Office Document Imaging
Extracts the relevant text and does 'whatever' with it.
I have done something like this before with pretty good results, but I would say it is a fragile solution. If the application changes, it stops working. If the OCR can't read the text, it stops working. If the OCR reads the wrong text, it might do worse things than stop working...
As the other posters have said, reaching into memory and pulling out data is a pretty advanced topic... kudos to you if you can figure out a way to do that!
I know this may not be a popular answer, due to the nature of what this software is used for, but programs like CheatEngine and ArtMoney allow you to search through all the memory reserved by a process for a given value, then refine the results till you find the address of the value you're looking for.
I learned this initially while trying to learn how to better protect my games after coming across a trainer for one of them, but have found the technique occasionally useful when debugging.
Here is an example of the technique described above in use: https://www.youtube.com/watch?v=Nv04gYx2jMw&t=265
I couldn't find a suitable title for this. I'm going to express my query with examples.
Consider following softwares:
Process explorer from sysinternals (an advanced task manager)
Resource Manager : resmon.exe (lists each and every fine detail about resource usage about each process).
For me these softwares seems like miracles. I wonder how these are even made. C'mon how a user process can know such fine details about other processes? Who tells this software, what processes are running and what all resources are utilized? Which dlls are used? etc..
Does windows operating system give these software that information? I mean though (obviously the most lower level api) WIN32API. Are there some functions,which on calling return these values
abstractly say:
GetAllRunningProcesses()
GetMemoryUsedByProcess(Process* proc)
etc..
Other similar applications are
network Packet Capture software. How does it get information about all those packets? It clearly sits just infront of the NIC card. How is it possible?
Anti-virus: It scans memory for viruses. Intercepts other processes. Acts like a sandbox for the user application space. How? How??
If its WIN32API. I swear, I'm going to master it.
I don't want to create a multi-threaded application. I want to get information about other multithreaded applications.
I don't want to create a program which communicates using sockets. I want to learn how to learn how to capture all communication packets.
I actually want to work at the lower level. But I don't know, what should I learn. Please guide me in proper direction.
This is really a pretty open-ended question. For things like a list of running processes, look up "PSAPI" or "Toolhelp32". For memory information about a particular process, you can use VirtualQuery.
Capturing network packets is normally done by installing a device driver. If you look, you should be able to find a fair amount about how to write device drivers, though don't expect to create wonders overnight, and do expect to crash your machine a few times in the process (device drivers run in kernel mode, so it's easy for a mistake to crash the machine hard).
I can't say as much with any certainty about anti-virus, because I've never tried to write one. My immediate guess would be that their primary technique is API hooking. There's probably more to it than that, but offhand I've never spent enough time looking at them to know what.
Mark Russinovich's classic, Windows Internals, is the go-to book if you want to get deep in this kind of stuff. I notice that the just-released 5th edition includes Vista. Here's a sample chapter to peek at.
If you like Process Explorer, this is the guy who wrote that, and there are lots of examples using it in the book.
Plus, at 1232 hardcover pages, you can use it to press your clothes.
I wonder if it is possible to figure out what keys user was pressing while his Mac OS was starting up?
Any way will do. As far as I understand it there is no easy way to simply hook an app/script to start working and capturing keystrokes simultaneously along with the OS. But maybe there is a way to some kind of reverse engineer this? Maybe looking into a specific log file or something like that?
Any results will do. Basically what I'm interested in is in finding out, which key the user pressed/held during the OS startup. It may be string, a character code or a hex, doesn't really matter.
UPDATE: guided by Pekka's advice I've found a kernel extension that should do the job. And it, hopefully, will do it, after this follow-up question - Why this keyboard intercepting kernel extension doesn’t work? is answered. :)
I'm no OS guru, but I think very, very, very hardly. I don't suppose stuff like this is automatically recorded anywhere.
I guess you would have to look whether the part of the system that handles the startup keys is somehow accessible, and can be extended to invoke a command defined by you.
The second best thing that comes to mind is for you to write some sort of custom device driver or startup script that gets loaded at startup, and listens to keypress events.
How to approach this depends completely on what point in the boot process you want to check for keys.
If you want to check really early, your only choice is to play with the EFI (firmware) environment -- maybe you could modify rEFIt to do what you want?
After the firmware, control passes to boot.efi (BootX on PPC Macs). This could presumably be replaced/hacked, and I'd expect the source to be available from as part of Darwin, but I don't see it on a quick inspection.
After that, the kernel loads (you could build your own kernel) with a minimal set of cached drivers (you could write a driver, not sure how to get it to be cached, though).
After that, all sorts of things happen more or less at once. Normal drivers get loaded, /etc/rc.local gets run, launchd items in /System/Library/LaunchDaemons and Library/LaunchDaemons become active... If you're willing to wait until this phase of the boot process, you have many options.
It's not just not recorded anywhere, for quite a while during startup there is no keyboard driver. So from the point of view of software, during that interval the keyboard simply doesn't exist.