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.
Related
I'm using Redmon to start a .Net application that reads data from stdin, then send it to ghostscript to generate a .pdf file, before wrapping everything in a .zip file, which is uploaded to an ftp server.
The problem is, that under some Windows implementations, particularly Windows 10 Pro, the started process will run as user SYSTEM instead of the current user. However, it doesn't seem to be the case every time. I have seen it running nicely on a pc for several weeks, and suddenly something must have changed, because the process began to run as SYSTEM, which makes my application fail because of missing registry entries and user-specific config files.
In Redmon, there is a setting called "run as user", which is enabled, but it doesn't really change anything. The documentation states that "this may or may not work".
I thought of letting the application fork a new process as the currently logged-in user, as suggested by others, but I only know how to do this by supplying a username and the user's password, which I don't have. I don't want to ask the user to enter his credentials.
So basically, I need to know why Redmon (or the Windows spooler) changes to the SYSTEM user on some systems, if this is a Windows setting, and if there is a way to avoid this. Alternatively, if I at least could have the SYSTEM process interact with the desktop, it would also be a step in the right direction.
I have an program which I need to run on multiple PCs (>100) all in same domain and share the same user and password.
If I run a program manually, it opens a console windows where I can see the logs running. I can remote desktop and still be able to see the console windows open and logs running. It helps in debugging as I can see whats going on. Issue is I want to avoid running it manually on all PCs.
I have following requirement
a. It should be able to run program on multiple pcs remotely
b. program should open in foreground where console logs can be seen.
c. launching PC should launch program on PC1 and then (without wait for the program to finish on PC1) it should launch the program on PC2 and so on.
I explored STAF it needs to be installed on all stations. Its heavyweight, needs complex configuration.
I explored power shell , it needs to be enabled on all stations and also probably (read somewhere) has issue with running tasks in foreground.
psexec can run the program but it does it in background, if I use -i option I need to give session id so only it will show the console for a specific remote desktop session. Another major issue with -i is that it will interactive so it waits until the program exits.
Looked a paexe, its simillar to psexe and doesn't solve the issue I am facing with psexe.
Any help is greatly appreciated.
If you have a server, you can put the program on the server and create a shortcut to it (assuming the program is small/simple enough to run on a network share).
You can use One-Click to deploy the programs, and give each of your users a link.
You can change the program into a website for central access.
You can use group policy to deploy the program when a user logs in, assuming you can create a .msi file from it.
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,
I've tracked down an error in my logs, and am trying to reproduce it. My theory is that a file sometimes gets locked in a specific folder, and when the application (ASP.NET) tries to delete that folder it hangs.
I don't have the application running on my own machine so I'm debugging this on a remote server. But for the life of me, I can't seem to figure out a way to lock a file that prevents it from being deleted by the process.
My first thought was to map the network path to a local drive and just leave a command prompt open to that folder. Locally that always fouls up my folder deletes, but apparently SMB is a bit more robust and doesn't grant me a lock.
After that I created an infinte loop vbscript in the folder and executed it remotely. The file was deleted out from underneath the executing code. Man!
I then tried creating a file on the server in that folder and removing all permissions. That didn't do the trick. I don't have access to the IIS settings so perhaps it's running under a privileged system account.
So: what's a program that you know is free and I can quickly use to create an exclusive lock on a file so I can test my delete theory? Like a really, really bad Notepad clone or something.
:-)
Can't you just create a text file from a network folder and open it with MS Word/VS or a similar program which locks it during editing?
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.