I am getting the error "Publisher could not be verified. Are you sure you want to run this software" while opening an exe from UNC path. when I am trying to open an exe from UNC path (\abcserver\apps). There were two possible solutions but didn't work as I want.
This is an application accessing by 50+ people from the network share. As per the given solutions on the forums, I've added the intranet security to the zone with all options on.
(------Open Internet Explorer | Tools | Internet Options | Security
selected Local Intranet | Sites
Check all of the three selection boxes.
Now add the server as: \abcserver------)
But we don't want each and every user to add the security on their local machines. Anyway added the same to \abcserver as well. Is there a way to fix this more efficiently?
Thanks you.
The warning is because your EXE is not digitally signed.
You can either
Copy the EXE locally (maybe create an install program?)
Change the user's security settings so there's no warning (you've found out about this already). You might be able to automate this, to reduce the user pain & chance of error.
Sign the EXE. More details here (general) and here (VB6-specific). Nb you will have to buy a certificate. Self-signing won't remove the security warning AFAIK unless perhaps you change the security settings to trust the certificate & it sounds like you're trying to avoid that.
Worked for me ...
Move the exe file to a non-ntfs volume (e.g. a USB flash drive (FAT)), then move it back again.
IT seems to be something to do with an NTFS property in the .exe file, which FAT does not have. So moving to a FAT drive removes it, and when moved back the propoerty is gone!.
See https://social.msdn.microsoft.com/Forums/vstudio/en-US/fc98080e-db2a-463f-a3a0-372acb3b6eab/disable-the-publisher-could-not-be-verified-for-a-certain-application?forum=windowssecurity
Related
I have built a Windows executable (with MSVC++) requiring administrator privilege to run (it indexes files) ; I even code-signed it with a code-signing certificate I bought.
It works well on Win7, Win8, but on Windows 10, if I download the file from the browser, then I get this message from IE/Edge:
This file contained a virus and was deleted
and it's nearly impossible for a (non power-user) user to have access to the ZIP, extract it, and run the .exe. (It's very complicated to find the right quarantine place, and remove it from quarantine, etc.; and also it's non-ok for a commercial product)
It's clearly a false positive (I have no virus, and I checked it with many antivirus, and https://www.virustotal.com).
What solution is there? (I thought I had tried all I can do by even code-signing it with a certificate from a well-known CA)
The file was detected by Windows Defender as a file system indexer. All these files could be considered as a threat. You should report your file as safe to Microsoft.
First of all, I'd suggest you to check if you've enabled "Real-Time Protection" and the other settings in the Windows Defender settings. Windows 10 is running almost every file through it before it gets executed (this feature is called SmartScreen and included in RealTime-Protection), so maybe that is what causes it.
If it happens even earlier, whilst downloading, then chances are that this is in your IE/Edge Settings. Unfortunately I am not aware where these settings are exactly (feel free to edit this answer if you know where they are), so I can't help you with that one.
If everything else fails, try switching to a different browser. I'm using Brave myself. It's a modified version of Chrome with a few additional features, but the choice is yours. Just make sure to disable the download protection in the settings as well. A quick browse through your privacy settings should usually allow you to change these settings.
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.
We have a program that the installer checks for the existence of a config file, and if it exists, it doesn't copy that file over (it assumes the user has modified their config file and wants to keep those modifications). Unfortunately, this is a pre-Vista application and it keeps the config file in Program Files. The problem is, if you manually wipe out the directory when it re-installs certain API still thinks that there is a directory there. VB6, for example, and its browse for file dialog sees the folder, however explorer, cmd shell, etc cannot see folder. Writing over the file still leaves the old file there (to some API's, but not to explorer) which cannot be removed except form within the Browse for File dialog.
What is going on with these Phantom folders, and how do we delete the file so that all API's see the same thing? Maybe it has something to do with TxF, or the indexer for search, but both the installer we use (InnoSetup) and parts of the application (the parts written in VB6) are seeing the old version of the file, and everything else sees the current version.
As Oskar Duveborn said, it's very likely that what you're seeing is Vista's virtualization behaviour.
When a machine has User Account Control (UAC) enabled, standard users and non-elevated programs aren't allowed to write to the Programs folder. Windows instead silently redirects files to the appropriate subfolder of %AppData%\Local\VirtualStore (for example, C:\Users\MyUser\AppData\Local\VirtualStore).
If you browse the real folder in Explorer, you'll see the 'Compatibility Files' toolbar button, which you can use to browse the virtual store instead.
Note that this is only compatibility behaviour from Windows - your program should write to its own subfolder of %AppData%.
For more information, see this TechNet Magazine article.
Dunno if I'm on the right track, but doesn't Vista virtualize %programfiles% for applications that tries to write to it or otherwise are flagged as "not going about this the right way"? (and hence moves it somewhere into the user part of the filesystem instead, without telling the legacy app about it - making it kinda transparent)..?
Virtual Store Redirected files are stored somewhere in %appdata% - you can also find out the location by checking the "Compability Files" option in Explorer when at the aliased location. You need to stop writing to %programfiles% to get rid of this behaviour as far as I know.
Do you mean the AppData folder (C:\Documents and Settings\UserName\AppData)? I'm not on my vista machine, but I think that's the path, and afaik it's not wiped after an uninstall.
The TechNet link by Ant above (accepted answer) is no longer valid. The new link is:
http://support.microsoft.com/kb/927387 - Common file and registry virtualization issues in Windows Vista
I've built an installer for my application by hand (don't ask why). And I set up the registry keys for its entry in the add/remove control panel under HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall. And it works fine. I need it to be under HKCU so my installer will run on Vista without asking to be elevated.
The issue I have is that if a user installs using a domain account with a roaming profile, and then goes to a different machine, there's an entry for my software in the add/remove control panel with no information in it. I don't want it to appear there for roaming users, my app does not get installed in such a way that it will work in that circumstance anyway. Is there anyway I can setup that entry so my app won't appear in the add/remove? Or have I doomed myself to it by making the entry under HKCU? Thanks!
fwiw:Google Chrome installs the way you did, but also suffers from the same problem since it installs in the profiles "local settings\app data" directory, which doesn't roam [1].
Rather than fix the install\uninstall problem, would it be reasonable to have your app roam with the user? Is it small and xcopy installable such that you could install it under Doc & settings\Application Data some place, which does roam?
[1] http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dseb_ovr_wpeu.mspx?mfr=true
The title says it. I'm looking for a way to determine exactly which file/registry key this executable is attempting to access. I have attempted to use Windows auditing capabilities and Process Monitor to determine where the failure is happening but, this failure does not produce audit failure events or show as access denial in Process Monitor.
Of course, If someone has experienced this and can provide a solution to resolve the error directly that would be almost as nice.
Background:
I am using moveuser.exe which is part of the Windows Server 2003 Resource Kit Tools to convert the security of local user profiles on a number Windows XP workstations.
Symptom:
Occasionally, moveuser.exe will fail to convert the security of a profile with the error "Error: 5 access denied". I have not been able to determine any commonality among the failing accounts or the computers they reside upon. A given computer may have host 6 profiles, 5 of which convert without issue and 1 which produces the error.
There are a few factors that I'm as sure as I can be about:
-The account I'm using to run moveuser.exe with has full Administrator rights to the local machine and the domain to which the profile security is being converted.
-The failure is not related to file permissions within the profile directory (the entire directory can be moved, renamed, deleted, or successfully converted via a workaround).
I've developed a reliable workaround for these cases but, it is fairly involved and I would much rather understand the root cause of this error and correct it pre-emptively.
My workaround (glad to share it, left out for brevity) seems to indicate that the failure is related to HKEY_LOCAL_MACHINE \ SOFTWARE\ Microsoft\ Windows NT \ CurrentVersion \ ProfileList registry keys but, I cannot determine exactly how/why.
Did you try to use the "regini" command line tool to grab registry permissions for the administrator account?
Use FileMon and RegMon (now Microsoft, formerly SysInternals, still free) to monitor what exactly is being accessed, how, and what rights/access are being requested.
I don't have a URL handy, but a Google search should be able to hook you up with these tools.
A couple items I would try. First, could it be that the user was logged in and the computer hasn't been rebooted. Microsoft has a product called UPHClent which helps in unloading unneeded user hives.
Next thing I wanted to know, is if you try rebooting before running the moveuser executable. This Conversation seems to indicate this would help with this kind of error.
Two days after posting this I got to the bottom of the problem. It turned out, just as Rob Haupt suggested to be related to a stuck user hive. The program I was running, moveuser, was reading the Refcount key found under HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ ProfileList\ <SID>\ and ending immediately.
Setting Refcount to 0 solved the problem immediately
Pushing out UPHClean to all the target machines pre-emptively has all but elimated the problem and we were able to successfully convert profiles on several hundred machines over the last week.
An important note about UPHClean:
I'd tried installing it previously but, it didn't appear to help. I was too impatient, the UPHClean ReadMe revealed that the service just takes time to do its job.