I'm trying to write values to the Run/RunOnce windows registry using PowerShell. The commands I'm using are successfully writing these values where they need to be. However, after I've written these values I need to power cycle the system (so we're skipping the shutdown process for various reasons) which is causing those values I've written to the registry never to be flushed to the disk (that's part of the shutdown process.) So once my system powers back up the Run/RunOnce commands are no longer in the registry halting my automation process.
My question: Is there anyway through a PowerShell command to force the flushing of a registry value?
You have to use syinternals Sync utility.
Related
I know that ntdll is always present in the running process but is there a way (not necessarily supported/stable/guaranteed to work) to create a file/key without ever invoking ntdll functions?
NTDLL is at the bottom of the user-mode hierarchy, some of its functions switch to kernel mode to perform their tasks. If you want to duplicate its code then I suppose there is nothing stopping you from decompiling NtCreateFile to figure out how it works. Keep in mind that on 32-bit Windows there are 3 different instructions used to enter kernel mode (depending on the CPU type), the exact way and where the transition code lives changes between versions and the system call ids change between versions (and even service packs). You can find a list of system call ids here.
I assume you are doing this to avoid people hooking your calls? Detecting your calls? Either way, I can't recommend that you try to do this. Having to test on a huge set of different Windows versions is unmanageable and your software might break on a simple Windows update at any point.
You could create a custom kernel driver that does the work for you but then you are on the hook for getting all the security correct. At least you would have documented functions to call in the kernel.
Technically, registry is stored in %WINDIR%\System32\config / %WINDIR%\SysWOW64\config, excepted your own user's registry which is stored in your own profile, in %USERPROFILE%\NTUSER.DAT.
And now, the problems...
You don't normally have even a read access to this folder, and this is true even from an elevated process. You'll need to change (and mess up a lot...) the permissions to simply read it.
Even for your own registry, you can't open the binary file - "Sharing violation"... So, for system/local machine registries... You can't in fact open ANY registry file for the current machine/session. You would need to shut down your Windows and mount its system drive in another machine/OS to be able to open - and maybe edit - registry files.
Real registry isn't a simple file like the .reg files. It's a database (you can look here for some elements on its structure). Even when having a full access to the binary files, it won't be fun to add something inside "from scratch", without any sotware support.
So, it's technically possible - after all, Windows does it, right? But I doubt that it can be done in a reasonable amount of time, and I simply can't see any benefit from doing that since, as you said, ntdll is ALWAYS present, loaded and available to be used.
If the purpose is to hack the current machine and/or bypass some lack of privileges, it's a hopeless approach, since you'll need even more privileges to do it - like being able to open your case and extract the system drive or being able to boot on another operating system on the same machine... If it's possible, then there is already tools to access the offline Windows, found on a well-known "Boot CD", so still no need to write in registry without any Windows support.
I want to set up path redirection in both files and registry keys in the same manner UAC virtualization works for another process at launch time (either programmatically or using some existing interface).
For example, I want to run C:\my_path\app.exe and when it opens any file on disk (C:\other_path\file.txt) for writing, the actual open file should be C:\temp_for_my_app\C\other_path\file.txt.
I've seen some programs are able to set up such redirection (i.e. Sandboxie), but I'm unsure which mechanism they are using (not even sure if it is the same UAC virtualization uses).
Any insight into the way UAC virtualization implements it might be useful (your comment on this will be appreciated)
Try cmregistercallback() or API HOOKING to hook zwopenkey() and zwcreatekey()
Is it possible to cut users' connections to a SAS server programmatically from the server? I know I can kill individual SAS processes by using standard Windows tools such as Task Manager when I have a remote desktop connection to the server, but can this be done programmatically, and moreover, can we prevent any users from connecting?
The situation is as follows:
We have a SAS 9.4 installation on a Windows Server 2008 R2 server. There's a bunch of folders on the server with SAS tables in them, and a bunch of end users who use these SAS tables through SAS Enterprise Guide (that has been installed on their desktops). Now, there's also a large SAS batch run, that we run every day to update all SAS tables. We would like to make sure that no users have any SAS tables opened through EG when the batch run is running; otherwise it might fail because a table is locked. Of course, the batch run is usually done at nighttime, but as its schedule depends on many other things we cannot be 100% certain it is completed before people come to work.
What we want is some kind of a script or SAS setting that would allow us to automatically cut all users' SAS connections before the batch run starts, keep them out during the run, and then allow them to reconnect when the batch run is complete.
Any hints would be appreciated!
Edit: Would it be possible to write a cmd-script using taskkill that would stop all sas.exe processes running under any other user than the current one? Does SAS actually even create a sas.exe process on the server for each user in this case?
You can use the SYSTASK or X commands in (Windows) or (UNIX) . My extract, transform and load (ETL) process runs in the UNIX environment and SYSTASK is a big help for just the reason being asked about. I create the data sets with SAS then use the mv (UNIX) command to replace the existing data set. The file system will override the SAS lock.
As you are on 9.4, I put forward the suggestion that your library should be converted to a read-only, metadata bound library. This should prevent table locks, and negate the need to close user sessions (with potential impact on their productivity through loss of work tables / macro variables etc)
Look into SAS/Share. If that's not an option, then two ugly ideas are:
If the users are connecting using libname statements to a windows share you could just disable the share. Then re-enable it. This could easily be done using command line instructions and the x command.
If they are connecting through a SAS Service, stop the service and restart it. Again this can be done via the command line and x.
After doing either (or both) of the above. Make sure the first thing that happens is that you issue a lock <tablename>; statement to make sure no-one can use those tables again until your jobs are done. You can then restart the service/re-enable the shares.
Once you are finished, make sure that the SAS session that issued the lock command is either closed or clears the lock.
I'm writing an installer on NSIS that registers a shell extension.
On uninstall and upgrade, the old extension can't be deleted/overwritten since explorer.exe locks it, and killing-restarting the process is ruled out.
So I extract the new extension with a different name, mark the old extension for deletion (uninstall/upgrade) and rename the new extension to its original name (upgrade only) via PendingFileRenameOperations registry key. So far, this works fine.
The problem is, I have to register the new shell component on startup, since PendingFileRenameOperations only works on reboot. Is there a way to schedule a regsvr32 operation after rebooting?
I can't depend on doing this via a .bat execution on RunOnce, since logging off/logging on also triggers RunOnce operations.
Thanks in advance.
The simplest way I have found to resolve this issue, is to create a registry script that deletes all related registry keys and values. Run the registry script in the (un-)installer, and schedule a "delete on boot" for the COM DLLs. There might be a better way to do this, but I have yet to find it.
UNIX file-locking is dead-easy: The operating system assumes that you know what you are doing and lets you do what you want:
For example, if you try to delete a file which another process has opened the operating system will usually let you do it. The original process still keeps it's file-handles until it terminates - at which point the the file-system will quietly re-cycle the disk-resources. No fuss, that's the way I like it.
How different things are on Windows: If I try to delete a file which another process is using I get an Operating-System error. The file is untouchable until the original process releases it's lock on the file. That was great back in the single-user days of MS-DOS when any locking process was likely to be on the same computer that contained the files, however on a network it's a nightmare:
Consider what happens when a process hangs while writing to a shared file on a Windows file-server. Before the file can be deleted we have to locate the computer and ID the process on that computer which originally opened the file. Only then can we kill the process and delete our unwanted file.
What a nuisance!
Is there a way to make this better? What I want is for file-locking on Windows to behave a like file-locking in UNIX. I want the operating system to just let me do what I want because I'm in charge and I know what I'm doing...
...so can it be done?
No. Windows is designed for the "average user", that is people who don't understand anything about a computer. Therefore, the OS tries to be smart to avoid PEBKACs. To quote Bill Gates: "There are no issues with Windows that any number of people want to be fixed." Of course, he knows that 99.9999% of all Windows users can't tell whether the program just did something odd because of them or the guy who wrote it.
Unix was designed when the world was more simple and anyone close enough to a computer to touch it, probably knew how to assemble it from dirty sand. Therefore, the OS usually lets you do what you want because it assumes that you know better (and if you didn't, you will next time).
Technical answer: Unix allocates an "i-nodes" if you create a file. I-nodes can be shared between processes. If two processes create the same file (that is, two processes call create() with the same path), then you end up with two i-nodes. This is by design. It allows for a fancy security feature: You can create files which no one can open but yourself:
Open a file
Delete it (but keep the file handle)
Use the file any way you like
Close the file
After step #2, the only process in the universe who can access the file is the one who created it (unless you want to read the hard disk block by block). The OS will keep the data alive until you either close the file or your process dies (at which time Unix will clean up after you).
This design is the foundation of all Unix filesystems. The Windows file system NTFS works much the same way but the high level API is different. Many applications open files in exclusive mode (which prevents anyone, even backup programs) to read the file. This is even true for applications which just display information like PDF viewers.
That means you'll have to fix all the Windows applications to achieve the desired effect. If you have access to the source, you can create a file in a shared mode. That would allow other processes to access it at the same time but then, you will have to check before every read/write if the file still exists, whether someone has made changes, etc.
According to MSDN you can specify to CreateFile() 3rd parameter (dwSharedMode) shared mode flag FILE_SHARE_DELETE which:
Enables subsequent open operations on a file or device to request delete access.
Otherwise, other processes cannot open the file or device if they request delete access.
If this flag is not specified, but the file or device has been opened for delete access, the function fails.
Note Delete access allows both delete and rename operations.
http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx
So if you're can control your applications you can use this flag.
Note that Process Explorer allow for force closing of file handles (for processes local to the box on which you are running it) via Handle -> Close Handle.
Unlocker purports to do a lot more, and provides a helpful list of other tools.
Also deleting on reboot is an option (though this sounds like not what you want)
That doesn't really help if the hung process still has the handle open. It won't release the resources until that hung process releases the handle. But anyway, in Windows it is possible to force close a file out from under a process that's using it. Process Explorer from sysinternals.com will let you look at and close handles that a process has open.