I had an application installed on my windows machine which I removed, but it has left an orphaned drive icon under "My Computer". Having dug through the registry, to find it by name, it seems to be associated with a GUID that occurs in other parts of the registry. I'd like to write a quick C program to do the job, once I understand what it is I need to remove. I understand the API, but what is all that cr*p in the registry? Short question: what registry values do I need to remove to reliably delete the unused drive icon? Longer question: where do I find out how the windows registry is organised at that level, to achieve the required result? I've looked on MSDN, but either the information I require is not there, or I don't know what I'm looking for (I'm not a windows programmer, but I do know a little about coding...). RTFM answers welcome, I'd just like to know which FM to R...
Have you tried tools like CCleaner?
Short anser to the longer question:
No such documentation exists. The registry is a rather ad-hoc pile of data, shared between many developers in- and outside Microsoft.
Try RevoUninstaller if CCleaner does not help and you have not already coded something for this yet.
TFM - About the Registry
TFM - COM Registry Entries
TFM - Shell Extensions
TFM - Registering Verbs for File Extensions
TFM - Registering Preview Handlers
TFM - Registering Programs with Client Types
As easy as eating pancakes
Related
I was tasked to set up an open-source icap-server to scan files that are uploaded in one of our web applications.
The files base64-encoded withing the upload method and this seems to lead to the fortigate not being able to scan it properly.
Now I managed to set up an icap-server using "c-icap" and tested it with "clamav". So far it seems to work, at least EICAR files are detected.
Now the problem is, that my boss is basically a "Windows-only" person who says that any open-source AV can´t be trusted enough.
He wants me to try to have the requests/uploads sent to the c-icap server, but scanned with Windows Defender. ß Is there any - useful - way to accomplish this? Also, since I am super new to ICAP - are there any restrictions regarding which icap-server can be used?Like, is there any way to force requests to be handled with a metadefender-icap only, and not any other icap server?
Sorry if these questions are a bit unspecific and basic, but just started with ICAP yesterday!
Thank you!
Check out this link: https://techcommunity.microsoft.com/t5/windows-it-pro-blog/metadefender-icap-with-windows-defender-antivirus-world-class/ba-p/800234 to see what Microsoft offers regarding Defender+ICAP.
I have used commercial ICAP solutions in the past (like Bluecoat) that allow plugging in multiple commercial virus engines (Kaspersky, Sophos, ...).
These are appliances, and you don't need to tell your boss their internals are probably some sort of Linux ;-)
You can probably also set up a commercial antivirus solution on your Linux system and use that.
Looking at this link: https://learn.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/microsoft-defender-atp-linux it may even be possible to run Microsoft's Defender on Linux. I haven't tried it myself though.
Unlike your boss, Microsoft realizes software shouldn't be made to just run on Windows anymore (even MS-SQL Server now runs on Linux).
I've seen several questions that are the opposite of this; "How do I disable virtualization?" That is not my question. I want to force an application to run with virtualization enabled.
I have an application that ran just fine under Windows XP, but, because it writes its configuration to its working directory (a subfolder of "C:\Program Files (x86)"), it does not work completely under Windows 7. If I use task manager to turn on UAC Virtualization, it saves its config just fine, but of course it then can't load that config.
I do not want to set it to run as administrator, as it does not need those privileges. I want to set it to run with UAC Virtualization enabled.
I found a suggestion that I put some magic in the registry at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags. For completeness I also put it in Wow6432Node, but neither had any effect.
File system is virtualized in certain scenarios, so is your question how to still turn it on when your application does not qualify? It is unlikely possible, MSDN:
Virtualization is not in option in the following scenarios:
Virtualization does not apply to applications that are elevated and run with a full administrative access token.
Virtualization supports only 32-bit applications. Non-elevated 64-bit applications simply receive an access denied message when they
attempt to acquire a handle (a unique identifier) to a Windows object.
Native Windows 64-bit applications are required to be compatible with
UAC and to write data into the correct locations.
Virtualization is disabled for an application if the application includes an application manifest with a requested execution level
attribute.
this may come way too late now, but I am the author of the suggestion you found to activate UAC virtualization, and there was a mistake in my post. The registry keys to modify are the following:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\
(notice the "Layers" appended)
so a full example would be:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="RUNASINVOKER"
note that multiple parameters must be separated with space character.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Program Files (x86)\\Some Company\\someprogram.exe"="WINXPSP3 RUNASINVOKER"
--
I'm sincerely sorry that you lost a fair amount of time because of my mistake.
And by the way, let me express my disagreement with Ian Boyd's post. There are places where write privileges should not be granted to everyone, such as this one, since it breaks the base security rule of "System-wide writes should be authorised to privileged principals only". Program Files is a system-wide place, not a per-user one.
All rules have exceptions of course, but in the present case, one could imagine a maliciously crafted configuration file making the program exec an arbitrary command as the user running it. On a lighter side, one could imagine a "mistake delete" by another user, which would make the app fail. Back on the heavier side, application executables in Program Files are often run by the admin, sooner or later. Even if you don't want to, uninstalling programs very often run uninstall executables that are in Program Files. Maybe the uninstall procedure will use that config file which could have consequences if it's maliciously crafted.
Of course you may say, this sounds paranoid somehow, agreed. I did modify some NTFS ACLs in Program Files at the times of Win XP and was able to sleep after that, but why take the slightest risk when the tools are available ?
I found one not very well cited condition where UAC Virtualization does NOT work: when the file in Program Files is maked as read-only.
That is, suppose the file C:\Program Files\<whatever>\config.ini is marked as read-only. When the application try to change it, UAC Virtualization will return an access denied error instead of reparsing it to %LOCALAPPDATA%\VirtualStore\<whatever>\config.ini.
Although I did not found this documented, this behavior is probably done by design, since it makes some sense.
The solution is simple: assure that all files that are supposed to be modified by the application are not read-only (or just unflag all files, since the user will not be able to change them anyway).
You have an application, and you want users to be able to modify registry keys or files in locations that by default only Administrators can modify.
If you were running Windows 2000, or Windows XP, or Windows Vista, or Windows 7, or Windows 8, the solution is the same:
grant appropriate permissions to those locations
For example, if your program needs to modify files in:
C:\Program Files\Blizzard\World of Warcraft
Then the correct action is to change permissions on the World of Warcraft folder. This is, in fact, a shim that Microsoft applied to World of Warcraft. (On next run it granted Everyone Full Control to the folder - how else can WoW update itself no matter what user is logged in.)
If you want users to be able to modify files in a location: you have to grant them permission. If you were a standard user trying to run WoW on Windows XP you will get the same problem - and need to apply the same solution.
Your application is writing its configuration to:
C:\Program Files (x86)\Hyperion Pro\preferences.ini
then you, in fact do want to grant Users Full Control to that file:
So your:
application is not set to run as an Administrator
users cannot modify the executable
users can modify Configuration.ini
Granting permissions is not a bad thing; it's how you administer your server.
There are two solutions:
Install to C:\ProgramData\Contoso\Preferences.ini and ACL it at install time
Install to C:\Program Files\Contoso\Preferences.ini and ACL it at install time
And if you look at the guidance of the AppCompat guy at Microsoft:
Where Should I Write Program Data Instead of Program Files?
A common application code update is this: “my application used to write files to program files. It felt like as good a place to put it as any other. It had my application’s name on it already, and because my users were admins, it worked fine. But now I see that this may not be as great a place to stick things as I once thought, because with UAC even Administrators run with standard user-like privileges most of the time. So, where should I put my files instead?”
FOLDERID_ProgramData
The user would never want to browse here in Explorer, and settings changed here should affect every user on the machine. The default location is %systemdrive%ProgramData, which is a hidden folder, on an installation of Windows Vista. You’ll want to create your directory and set the ACLs you need at install time.
So you have two solutions:
create your file at install time, and ACL it so that all users can modify it at runtime
create your file at install time, and ACL it so that all users can modify it at runtime
The only difference is semantic. The Program Files folder is mean for program files. You don't want to store data here.
And it's not because Diego Queiroz has any insight about security.
It's because it's where just the programs go.
Sometimes machines are imaged with the same Program Files over and over. You don't want per-machine data in your image. That data belongs in ProgramData.
And it's not a security issue.
Some people have to learn where the security boundary is.
there are quite some good points in those other answers.
actually i have upvoted all of those.
so let's all combine them together and add some more aspect ...
the OP mentions some "legacy application from the old days".
so we can assume it is x86 (32bit) and also does not include any manifest (and in particular does not specify any "requestedExecutionLevel").
--
Roman R. has good points in his answer regarding x64 and manifest file:
https://stackoverflow.com/a/8853363/1468842
but all those conditions don't seem to apply in this case.
NovHak outlines some AppCompatFlags with RUNASIVOKER in his answer:
https://stackoverflow.com/a/25903006/1468842
Diego Queiroz adds intersting aspect regarding the read-only flag in his answer:
https://stackoverflow.com/a/42934048/1468842
Ian Boyd states that probably you don't even should go for that "virtualization", but instead set according ACL on those files of interest (such as "config.ini"):
https://stackoverflow.com/a/12940213/1468842
and here comes the addtional / new aspect:
one can set a policy to disable all virtualization - system-wide:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableVirtualization"=dword:00000000
actually i'm enforcing this policy on each and every system that i own.
because otherwise it will lead to confusing behaviour on multi-user environments.
where UserA applies some changes and everything goes fine.
but then UnserB does not get the changes done by UserA.
in case some old crappy software fails then it should "fail"!
and not claim that everything went "fine".
IMHO this "Virtualization" thing was the worst design decision by microsoft, ever.
so maybe the system has this policy enabled and that's why virtualization doesn't work for you?
--
so probably the ultimate checklist would be:
is the application x86 or x64?
does the exe have a manifest (including the requestedExecutionLevel)?
have you checked the read-only attribute (e.g. of those INI files)?
is there a policy to force the EnableVirtualization to 0?
have you tried the AppCompatFlags with RUNASIVOKER?
or simply go for ACL instead of virtualization
--
in the end we are discussing how to get on old legacy application to run.
by using whatever workarounds and hacks we can think of.
this should probably better discussed on either superuser or serverfault.
at stackoverflow (targeted for programmers) we all know: it's about time to get all of our own programs compatible with UAC concept and how to implement things the "right" way - the "microsoft" way :)
I am trying to write a simple program, preferably in C, that will watch a given directory. Whenever a process accesses that directory, I just want to print out the name of that process. It seems simple, but I am coming up short for solutions on MSDN. Does anyone know which library calls I will need for this, or any helpful advice? I have considered repeatedly querying for what processes have handles on the given directory and just watching for additions to that list.This approach just seems very intensive and I am hoping there is an easier way. Thanks.
I'm not sure if there's an easier way, but one way is to use a file system filter driver. Or easier a file system minifilter driver.
You can filter, log, track, control, ... all IO.
There is no supported way to do this from user mode. You can use the FindFirstChangeNotification API to tell when a file or directory has changed, but that doesn't tell you who did it. You might be able to hook some things to obtain this information... but that is of course not supported.
If you can use a driver, you can use Event Tracing for Windows for this information. This is what Sysinternals ProcMon uses. But installation of a driver is a very invasive process, bugs in your driver cause BSODs, and installation of a driver requires administrative rights. Something to keep in mind.
I have a requirement where my client want to install a custom "Print to File" printer (apparently MS has an SDK for this?). They want to be able to install this as a kind of "application" so that if someone chooses to print to this printer, they have to answer a few questions, and the file gets "printed" to a path of our choosing. (we will then do some other things with the file such as rename it and SFTP it)
I have tried googling, looking for things such as "customize print to file" and I have found nothing. Does anyone have any experience with this and can give me a kick in the right direction?
EDIT: I would rather have a c# oriented solution but I am willing to take anything right now.
Edit 2: The idea is for this "custom print driver" is for a document imaging company to provide an easy method for their customers to store/archive documents. The idea, is that the customer, if they want to store/archive a document, they would print, from standard windows applications such as Word, Excell, Acrobat Reader, Web Pages, etc., to the "company X" printer driver. When doing so, the document would get "printed" to a file in a specific location that another application (which has a filewatcher service on it, which would rename it and send it to the SFTP server), knows to watch. The document that is printed to the file, should ideally also be able to come out on paper (AKA just like normal). When printing to the "Custom print driver", we also need to have a form filled in which would provide meta-tags for the archiving system, which would also be uploaded to the document imaging system.
I am not looking to recreate a printing application, nor am I looking to add "printing" into a custom application. This needs to work at the Windows level.
I have no problems with the SFTP, FileWatcher, Alchemy integration (the document archiving application) or the document renaming portion. It's the "custom print driver" that I am having issues with. This is all compounded by the fact that when installing the application, I need to automatically install the "custom print driver", and configure it during the install process. Essentially the solution needs to be installed as a printer available under "My Printers" and should be available for any type of document, Word, Excell, PDF, etc. Oh, and it needs to be availabe for XP, Vista, and Windows 7 . . . . :(
Thanks in advance for everyones help. I have a feeling that this one is going to be a doozy :(
Hah! I knew I'd seen at least one...
ActMask Virtual Printer Driver
Can't make a recommendation of any sort not having tried this particular toolkit - but it would appear to me to bear a strong resemblence to the sort of solution you're after.
What kind of customization you are talking about? Can't you use the .Net inbuilt one?
I need to save a user's login information in encrypted form for this application I'm building, but I'm not sure of the best place to save the file. I don't want to save it into the program application folder as I want it per user.
So what is the best folder (or way) to save it into?
Edit: Using C++.
Seems like C:\Documents and Settings\%username%\Local Settings\Application Data may be the appropriate place according to Wikipedia. The article says this location is used for "User-specific and computer-specific application settings".
Edit: Cruizer pointed out in the comments (I'd reply there but I can't comment yet) that in Vista it is C:\Users\%username% and that it shouldn't be hard-coded. Thanks.
Use the Data Protection API (DPAPI) - a part of the CryptoAPI in XP and Vista. Here's a good overview of DPAPI - http://msdn.microsoft.com/en-us/library/ms995355.aspx
Yeah, local application path looks like a winner.
I found this article in MSDN to get it in C++: http://msdn.microsoft.com/en-us/library/bb762494.aspx
Example:
char localAppPath[MAX_PATH];
SHGetFolderPath(NULL, CSIDL_LOCAL_APPDATA, NULL, SHGFP_TYPE_CURRENT, localAppPath);
are you using .NET? how about IsolatedStorage? That way you wouldn't have to worry about the directory location, it'll just be there...
User information should always go in some sub directory in %HOMEDRIVE%%HOMEPATH% (Which maps to the users home directory). No exceptions.
A good place for application specific settings per user is a sub directory inside %APPDATA%. This maps to: "%HOMEDRIVE%%HOMEPATH%\Application Data" on XP and to: " %HOMEDRIVE%%HOMEPATH%\AppData\Roaming" on Vista.
If you are using .NET to get special folders you can use
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
or
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
for the non-roaming version.