In Win7 I observed that I can rename a running process file name, I searched about it and came across that this feature is introduced so that application itself can update the binary.
I have a windows service and I do not want to allow user to rename it when it is in running state. Please could anyone tell me how can I secure running process file from renaming?
Thanks,
Related
We run a 2022 azure Terminal Server with upwards of 100 users logged in. We have an application that most of these users can be running and when they are in this application there are many shared files that can be open. Every once in a while we get a locked file and we are having problems telling which user has the lock. We have used process explorer, but it only tells you who all have a handle to a particular file, it doesn't tell you who has is currently locked. Is there another tool that can tell us who has a particular file locked? We also don't want to just start logging people off just to find who had a file locked! Thank you.
The MCM IS NOT A OPTION.
I'm booting up a machine using a CD that runs a batch file, that applies an image to a machine using diskpart and imagex that formats the C drive and applies a custom .wim file. It basically formats the C drive and installs WES (Windows XP) operating system.
The user boots up from the CD, types in D:\Install.bat and off it runs.
This might seem a bit pointless, but I want to alter the boot behaviour to run the Install.bat file at boot time. So the user simply chucks in a disk and off it goes installing everything, instead of the user manually changing directories and calling the batch file.
I've tried using the Task Schedular and creating a registry file, but the Task Schedular didn't work and the registry file only worked when the user logged in.
Is there a way to change the boot up behaviour so it simply runs the Install.bat batch file?
I know this might not be the right place for the question but I didnt really know where to put it!
Thanks for your help!
EDIT: I've also tried placing the batch file inside the Startup folder, but this just runs it when I log in. What I want is for my Install.bat file to run before Windows even loads up.
I've written a Windows application. I want other applications to be able to programmatically launch my application. How can I achieve that and what are the considerations involved?
Edit: To clarify, I'm not asking how other applications can launch my application; I'm asking what I can do to ensure that other applications are able to launch my application.
To be able to launch an application without having to know the explicit path to where it is installed, you need to register it with Windows by adding it to the App Paths registry tree.
This is typically done during application installation.
See MSDN - Application Registration
In Windows, there is no security preventing an application from running another application (in user mode at least, to run in admin mode would require the other program to be executed in admin mode, or else to prompt the user to run it in admin mode). The other application simply needs to know the path to the location of your .exe file and it can execute it. If the other program doesn't know the exact path, but it knows where to look and what your program .exe is called, it can search for it in the file system before executing it as well.
As for specifically how they would launch your program's .exe file, this will depend on the the language their program is written in as to how the system API to launch the .exe is called.
I am using C# with .net 2.0
I am saving my program data in a file under: C:\ProgramData\MyProgramName\fileName.xml
After installing and running my application one time I uninstalled it (during uninstallation I'm removing all the files from "program data") and then I reinstall the application, and ran it.
The strange thing is that my application started as if the files in program data existed - means, I had old data in my app even though the data file was deleted.
When running:
File.Exists("C:\ProgramData\MyProgramName\fileName.xml")
I got "true" even though I knew for sure that the file does not exist.
The thing became stranger when I ran the application as admin and then the file didn't exist.
After a research, I found out that when running my application with no admin privileges instead of getting:
C:\ProgramData\MyProgramName\fileName.xml
I get
C:\Users\userName\AppData\Local\VirtualStore\ProgramData\MyProgramName\fileName.xml
and indeed there was a file that existed from the previous installation (that I obviously didn't delete, because I didn't know it existed).
So just guide me how could I stop this when apps running with no admin right.
I do not want to create any file automatically in VirtualStore folder. Please discuss all the possible ways to stop this.
First, ask yourself, do this need to be globally saved for all users?
If it doesn't have to be, save the file in Application Data instead, you can get the path with Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), it should always reliably expand to C:\Users\Username\AppData\Roaming\. Do note that this path is unique for each user though.
If you have to, you're out of luck. There is no reliable way to store application data for all users without admin rights (or UAC) on any Windows post-XP that's not extremely hacky, like storing your data in the Public user (which may or may not be possible, I can't check right now).
An approach to solving this is to use the Environment.SpecialFolder.CommonApplicationData location, but with some very important caveats & setup.
CommonApplicationData is
The directory that serves as a common repository for
application-specific data that is used by all users.
This location is described further here and here.
Important requirements and restrictions are given in another SO answer: https://stackoverflow.com/a/22107884/3195477
which said in part:
The recommended solution is for your installer to create a sub
directory of C:\ProgramData for your shared storage. And that sub
directory must be given a permissive ACL by the installation program.
That is what grants the desired access to all standard users.
Otherwise the program running with standard user permission will still not be all equally able to read/write files in that location for all users.
I found a work around for this issue when transferring a very old win32 app to windows 7 & 10. The program wrote to a database on C:\Program Files... but the OS auto changed the path to virtual store. However the database was required globally. By changing compatablilty mode to Windows 95 or XP SP2 and always running as administrator the database was worked on directly in C:\Program Files\etc.
There are security implications for this and the box was removed from all networks and adapters disabled etc.
My application running on a Windows server makes use of a Jet/Access database. For some reasons around every two weeks that database file gets locked by the System process (PID 4, seems to be fixed)
After some googling I found some other users having their files locked by that special process, but different files (of course).
What's the general reason for the System process to keep an open file handle?
Is my application the cause for this locking situation?
Are all handles implicitly opened by the System process? I could imagine that after a process has crashed, the handle may still be open and the System process somehow takes owernship of that handle.
Can I do something in my application to prevent it from happening?
Files accessed through a share will be locked by the system process (PID 4).
Try opening compmgmt.msc -> System Tools -> Shared Folders -> Open Files to see if the locked file is listed there
See also the sysinternals forum for a way to replicate this.
Not all applications lock files when they are opened, Excel however does. I don't know if Access does the same...
Here's another possible cause I've found:
There is a bug in Windows 7 and likely in Windows Server 2008 (possibly 64bit versions only). It surfaces when you disable Application Experience service and causes the same problems as described in the question.
Re-enabling this service has fixed this problem for me.
A bit more info here as to why it's causing a problem.
List of other SO questions which seem to be related:
Visual Studio output file permissions?
Windows 2008 R2 - Kernel (System Process PID=4) is locking files and folders
This sounds to me like a driver-level issue with a leaky handle.
If you're running an anti-virus package try upgrading, disabling (temporarily!) or switching to a different brand.
It may be a lingering session from a remote computer to a shared folder. If that's the case, it can be unlocked from the command line:
net session /delete
Is your server set up to perform periodic file backups?
If so, is the backup running as System, perhaps prompting the locked file when you get a conflict?
For me, it was "Windows Defender" (anti-virus). I excluded my Visual Studio build folders from Windows Defender's list of folders it checks, and the problem went away. (Visual Studio wasn't able to build to the EXE file, PID 4 was locking it to check for virii)
For me I had to hit it with a sledgehammer. Chkdsk /f on the drive where the folder was located fixed it. Use with caution.
Check the security settings for each folder and subfolders. Make sure that the system did not just automatically create a special permissions setting which will not allow anyone to delete the file. Apparently for some odd reason the OS creates a weird special permission setting that protects the file from being deleted.