how can my .NET application be informed that an application is about to be executed on the system ?
how can I then prevent if I want that application from executing ?
There are probably a couple of ways of doing this. The cleanest way to me is only possible in an environment with Active Directory. You can set group policies that control which applications can run. This approach may not be possible for you, or create a number of administrative headaches.
You may also be able to modify the RestrictRun registry key.
There are many articles showing how the System.Diagnostics namespace can be used to get a list of running processes. Your .NET application only really knows that the application is running when it is in he process list. You may be able to do something to discover when it is 'about' to be executed outside of .NET.
Once you find an application is running you can use System.Diagnostics to terminate a process.
The 'image hijack' approach that Process Explorer uses should work for this. See my answer here for details.
Related
Ok, the title is my question.
No, this ain't for malware. It is for a parental control program for my own netbook.
Yes, I am tired of my brother's friends visiting porn sites on my laptop when I am away.
Oh, yes, I have red other questions and don't do the "You can't!" thing. It must be possible.
Well, you could run several processes, and when one of them is killed, one of the others would launch a replacement. You can also run a service that would monitor the process and launch another process when the process is killed.
Sorry, I can't comment so I've posted this as a 'answer'.
A few things to consider:
Is a 13 year old or his friends going to notice a process in taskmanager that shouldn't be there? (for example a second explorer.exe, svchost.exe etc.)
What are you trying to actually achieve as there may be other ways to do what it is you want. Are you trying to block them from going on certain sites? Are you trying to monitor what they do? Are you trying to prove to your mum what they are doing? Something else?
Unless you are trying to block them, will they care about anything you may have running? Would they bother to look for 'logging' software running on the PC? I would guess that they wouldn't bother to even open task manager unless the sites weren't working.
If you are trying to give proof or monitor your pc, running a VNC service in the background allows you to connect a viewer from another computer so that you/your mum can watch a live view of what they are up to.
If you want to monitor the sites then you have a wide range of options: keylogging software, browser logging software, proxy software or logging software on your router
If you want to block the sites then you also have a wide range of solutions: hosts file, dns based blocking (e.g. openDNS), blocking software on the pc (e.g. netnanny), blocking software on the router, etc.
Remember: If you are trying to block sites remember that nothing will block 100% of websites. You will only achieve 1 of 2 things: (Ideally) it becomes too much effort trying to find sites not blocked and they use another computer for their porn -or- they persist and find a way around it/to disable it/sites that it doesn't catch
what about unstoppable service ? MSDN
Yes, it is possible, I recently wanted to do the same thing, just came across what is known as Protected Windows Services.
I know this requires a lot of effort but when it's successfully implemented there's no way not even Admin can kill the process.
You'll need to write an additional ELAM Driver for this to work :ELAM Prerequisites - Microsoft Docs
Here is the link where it is described
Register service as protected service
Posted this answer as an Idea ...... If there's any problem I'll delete it.
I'm building a console application which imports data into databases. This is to run every hour depending on an input CSV file being present. The application also needs to be reused for other database imports on the same server, e.g. there could be up to 20 instances of the same .exe file with each instance having their own separate configuration.
At the moment I have the base application which passes a location of config file via args, so it can be tweaked depending on which application needs to use it. It also undertakes the import via a transaction, which all works fine.
I'm concerned that having 20 instances of the same .exe file running on the same box, every hour, may cause the CPU to max out?
What can I do to resolve this? Would threading help?
Why not make a single instance that can handle multiple configurations? Seems a lot easier to maintain and control.
Each executable will be running in it's own process, and therefore, with it's own thread(s). Depending on how processor intensive each task is, the CPU may well max out but this is not necessarily something to be concerned about. If you are concerned about concurrent load then the best way may be to stagger the scheduling of your processes so that you have the minimum number of them running simultaneously.
No, this isn't a threading issue.
Just create a system-wide named Mutex at the start of the application. When creating that Mutex, see if it already exists. If it does, it means that there is another instance of your application running. At this point you can give the user a message (via the console or message box) to say that another instance is already running, then you can terminate the application.
I realize this thread is very old but I had the very same issues on my project. I suggest using MSMQ to process jobs in sequence.
As per the documentation, the program should have admin rights to create source for the event logger.
Can I log the error (Exception) in the event logs if the application is not running with admin rights?
Your setup should create the new source. This means that it requires elevated privileges. It's a normal setup behavior
It may be possible to use a generic existing source? That would solve your problems. But if not.
The best solution I've ever come across it either to need the install program to have a higher (admin) rights and have that to create the source, etc. Then your reduced rights application can create events using the previously created source. Another option if you can't modify the install program is just to have a separate app, again that must run with increased rights that creates the source for your application to run. In both this situation as part of the install/setup process you do need someone with admin rights to do it for you.
Luckily for me in this situation I've never had to do this for a large deployment, but for that situation maybe your infrastructure team could come up with a way of doing this, is there a windows platform way of creating event log source entries. That might be a better answer for serverfault as it's not really a programming question then?
I have an application which can only have 1 instance running at each time, however if a 2nd instance is launched it needs to be logged to a common logfile that the first could also be using.
I have the check for how many instances are running and I was planning on simply logging it to the event logger initially but the application can be running in user or system context and exceptions are thrown when attempting to query the eventlog source as a user so that idea is scrapped as the security logs are inaccessible to the user.
So I wanted to find out what the safest method of have 2 seperate instances of the same application write to a log file would be that would ensure both get an opportunity to write to it.
I would prefer not to use an existing additional framework if avoidable
Any help appreciated.
A Mutex could be used for interprocess synchronization of a shared resource such as log file. Here's a sample.
You could always write to the system event log. No locking or anything needed and the event viewer is more robust than some give it credit for.
In response to your comment, another user asked the question about write permissions for the event log here on SO. The answer linked to the msdn article that describes how to perform that.
See that question here.
You can dodge the problem if you prefer...
If this is a windows app, you can send the first instance a message and then just quit. On receiving the message, the original instance can write to the log file without any issues.
Why not use syslog protocol ? This will allow you to deliver the logs in a very standards-based and flexible manner. The protocol itself is quite simple, but there are plenty of examples on the Net, e.g. here. If your app is destined for the enterprise use, having a standard way of logging could be a big plus. (And, you do not need to maintain the files either - it becomes a job of a specialized software that does just that)
One way to hack it would be to memory-map the log file. That way, both instances of the application are sharing the same virtual memory image of the file. Then there are a number of ways of implementing a mutex inside the file.
I hate asking questions like this - they're so undefined... and undefinable, but here goes.
Background:
I've got a DLL that is the guts of an application that is a timed process. My timer receives a configuration for the interval at which it runs and a delegate that should be run when the interval elapses. I've got another DLL that contains the process that I inject.
I created two applications, one Windows Service and one Console Application. Each of the applications read their own configuration file and load the same libraries pushing the configured timer interval and delegate into my timed process class.
Problem:
Yesterday and for the last n weeks, everything was working fine in our production environment using the Windows Service. Today, the Windows Service will run for a period of around 20-30 minutes and hangs (with a timer interval of 30 secods), but the console application runs without issue and has for the past 4 hours. Detailed logging doesn't indicate any failure. It's as if the Windows Service just...dies quietly - without stopping.
Given that my Windows Service and Console Applications are doing the exact same thing, I can only think that there is something that is causing the Windows Service process to hang - but I have no idea what could be causing that. I've checked the configuration files, and they're both identical - I even copied and pasted the contents of one into the other just to be sure. No dice.
Can anyone make suggestions as to what might cause a Windows Service to hang, when a counterpart Console Application using the same base libraries doesn't; or can anyone point me in the direction of tools that would allow me to diagnose what could be causing this issue?
Thanks for everyone's help - still digging.
You need to figure out what changed on the production server. At first, the IT guys responsible will swear that nothing changed but you have to be persistent. i've seen this happen to often i've lost count. Software doesn't spoil. Period. The change must have been to the environment.
Difference in execution: You have two apps running the same code. The most likely difference (and culprit) is that the service is running with a different set of security credentials than your console app and might fall victim to security vagaries. Check on that first. Which Windows account is running the service? What is its role and scope? Is there any 3rd party security software running on the server and perhaps Killing errant apps? Do you have to register your service with a 3rd party security service? Is your .Net assembly properly signed? Are your .Net assemblies properly registered and configured on the server? Last but not least, don't forget that a debugger user, which you most likely are, gets away with a lot more stuff than many other account types.
Another thought: Since timing seems to be part of the issues, check the scheduled tasks on the machine. Perhaps there's a process that is set to go off every 30 minutes that is interfering with your own.
You can debug a Windows service by running it interactively within Visual Studio. This may help you to isolate the problem by setting (perhaps conditional) breakpoints.
Alternatively, you can use the Visual Studio "Attach to process" dialog window to find the service process and attach to it with the "Debug CLR" option enabled. Again this allows you to set breakpoints as needed.
Are you using any assertions? If an assertion fires without being re-directed to write to a log file, your service will hang. If the code throws an unhandled exception, perhaps because of a memory leak, then your service process will crash. If you set the Service Control Manager (SCM) to restart your process in the event of a crash, you should be able to see that the service has been restarted. As you have identical code running in both environments, these two situations don't seem likely. But remember that your service is being hosted by the SCM, which means a very different environment to the one in which your console app is running.
I often use a "heartbeat", where each active thread in the service sends a regular (say every 30 seconds) message to a local MSMQ. This enables manual or automated monitoring, and should give you some clues when these heartbeat messages stop arriving.
Annother possibility is some sort of permissions problem, because the service is probably running with a different local/domain user to the console.
After the hang, can you use the SCM to stop the service? If you can't, then there is probably some sort of thread deadlock problem. After the service appears to hang, you can go to a command-line and type sc queryex servicename. This should give you the current STATE of the service.
I would probably put in some file logging just to see how far the program is getting. It may give you a better idea of what is looping/hanging/deadlocked/crashing.
You can try these techniques
Logging start logging the flow of the code in the service. Have this parameter based so you dont have a deluge after you are done. You should log all function names, parameters, timestamps.
Attach Debugger Locally or Remotely attach a debugger with the code to the running service, set appropriate breakpoints (can be based on the data gathered from logging)
PerfMon Run this utility and gather information about the machine that the service is running on for any additional clues (high CPU spikes, IO spikes, excessive paging, etc)
Microsoft provides a good resource on debugging a Windows Service. That essentially sounds like what you'd have to do given that your question is so generic. With that said, has any changes been made to the system over the last few days that could aversely affect the service? Have you made any updates to the code that change the way the service might possibly work?
Again, I think you're going to have to do some serious debugging to find your problem.
What type of timer are you using in the windows service? I've seen numberous people on SO have problems with timers and windows services. Here is a good tutorial just to make sure you are setting it up correctly and using the right type of timer. Hope that helps.
Another potential problem in reference to psasik's answer is if your application is relying on something only available when being run in User Mode.
Running in service mode runs in (is it desktop0?) which can cause some issues in my experience if you are trying to determine states of something that can only be seen in user mode.
Smells like a threading issue to me. Is there any threading or async work being done at all? One crucial question is "does the service hang on the same line of code or same method every time?" Use your logging to find out the last thing that happens before a hang, and if so, post the problem code.
One other tool you may consider is a good profiler. If it is .NET code, I believe RedGate ANTS can monitor it and give you a good picture of any threadlock scenarios.