Application fails to start under Vista: "A referral was returned from the server." Manifest problem?

Question

I'm working on migrating a driver management application (written in Visual C++) to Vista. It requires access to HKLM, so it needs to run with admin access permissions. For testing purposes, we've been modifying secpol.msc to run it in admin approved mode, but obviously, that's not the right thing to do.

The right thing to do, from what I can tell, is to add a <trustInfo> tag to the application manifest (which is embedded in the .exe as a resource). I did that, but now the application fails to start under Vista at all, with the error message "A referral was returned from the server." It still works fine under XP.

The manifest is pasted below. Does anything look obviously incorrect? If not, is there anything that could interact badly with the <trustInfo> setting to cause that error?

Edit: This was under RC1, in case it makes a difference.

Thanks,
David

---------------------------------------------------------------

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="Microsoft.Windows.DriverMan"
type="win32"
/>
<description>Your app description here</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="true"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>

Answer 1

Hi David,

I'm running into this too. Have you found a solution?

Thanks,
   Bob

Answer 2

The same thing happens to me with an external manifest file, so it seems like something is off with the manifest file itself.  I have another much simpler program (all it does is attempt to remove a key from the HKLM area of the registry) that I wrote to test manifests that still works though, so I know that they do, in fact, work ... at least occassionally.

Answer 3

Hi Daniel,

I presume the manifest on the small program that works is the same as the manifest on the big program that doesn't?

It might help if we knew what a referral was and/or which server was returning it. It seems implausible that the manifest would force an internet access, so the server must be local. Is it a background process? Is it running on some systems and not others? Has it crashed?

To test whether it crashed, could you try running you program that fails, then your program that works? If a server has crashed in response to the first program, it should still be crashed for the second.

- Bob

Answer 4

   I got by this problem by changing the "uiAccess" parameter from "true" to "false."  I have another, smaller program where the manifest with uiAccess="true" works with no problem.  Apparently, this has something to do with the "User Account Control: Only elevate UIAccess applications that are in secure locations" option in secpol.msc.

   The "A referral was returned from the server" error seems to be how Vista responds to UAC denials.  If I enable the "User Account Control: Only elevate executables that are signed and validated" option and try either of my applications, I get the same error.

   It'd be really nice for developers if Vista actually gave UAC error messages for UAC-related failures...

David

Answer 5

This is the entirety of both manifests, one works, the other throws that error.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="Program Name"
     type="win32"/>
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

I should note that I receive the error prior to getting the elevation prompt and that I've had problems even getting a manifest to work with the program in question, so the issue may be something else.  I'll admit that I'm new to manifests and I'm uncertain which elements are absolutely necessary and which ones are not.  Frankly, I'd prefer to have the bare minimum required in the manifest for starters for the sake of ease :).

I have been trying to remotely debug the issue as well, to no avail as of yet but I will continue to forge ahead in hopes of stumbling across the answer (unless one presents itself here first).

Cheers,

Daniel

Answer 6

I was mistaken, the above manifest works, but when I change the uiAccess="false" to uiAccess="true" it throws the referral error.  That is the only difference between the two manifests. 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="Program Name"
     type="win32"/>
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

Works for my program

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="Program Name"
     type="win32"/>
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="true"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

Does NOT work for my program.

That seems to be an issue with UAC more than an issue with the program itself.

Cheers,

Daniel

Answer 7

I did a google search for the error and it linked me to an msdn page with results for Lightweight Directory Access Protocol applications.

http://windowssdk.msdn.microsoft.com/en-us/library/ms693297.aspx

I'm not sure how much this helps or if it is even applicable as I'm not aware that the program I'm dealing with does anything like that.  Ironically when I remotely debug the application using the offending manifest things work fine.

- Daniel

Answer 8

Reading the requirements for the Windows Vista Logo Program I found the following concerning the use of "uiaccess" :

"Applications that need to drive the input of the UI of another window may set uiAccesss=true, but will also need to apply for a waiver. Only accessibility applications will be considered for this waiver."

So my guess is that even though you write an MFC GUI application you will need to set this value to false, unless you write accessibility applications (which I don't).

Answer 9

Well, more manifest issues for me :(.

I just did a new build of my application and installed it onto Vista RC2.  The only known changes made were to a small section of code that was throwing errors when run on Vista, so I basically removed the functionality until I have more time to properly debug it.  That being said, the manifest that was finally working with the last successful build and install of the software is now not working with the latest build.

Does anyone have any clue as to why this might be?  The version number between the two didn't change any and I haven't added any internal manifests to the exe that might override my external manifest file, so I don't think that is the cause.

As always, any help would be greatly appreciated.

Cheers,

Daniel

Answer 10

Hi,

I run in the same problem.
Just to be sure, I do the things right, I've tried with notepad.exe.
When I add a manifest+sign with "requireAdministrator" but withtout uiAccess Attribute (or with uiAccess set to false), I get the prompt, ... and notepad works well.
BUT, if I add a manifest+sign with "requireAdministrator" AND uiAccess set to "true", I recieve always "A referral was returned from the server". No prompt for admin-rights, only "A referral was returned from the server".
Could someone help?
Where are the microsoft vista gurus?!?

Thx

Answer 11

My immediate response is that you never need the "uiAccess" to be set to "true". Atleast I have not encountered a need for it.

Answer 12

Sorry Rasmus Christian Kaae, but I DO need uiAccess="true" even 99% of the applications don't need it!!

I could also say, if this flag exists, then it must be useful, else it wouldn't exist!

Answer 13

"I could also say, if this flag exists, then it must be useful, else it wouldn't exist!"

Or it is just a hack from the MS-development team. Out of curriosity, why do you need to access the GUI of another running application?

Answer 14

Hi,

Well, it's very simple.

I'm trying to make Visual Test run under Vista!!! That's why I DO need that this flag works.

I can find everywhere, also by microsoft, that this flag exists, what it does, ... but it seems, it doesn't work properly. Did I find the "first" bug in Vista?!?!

If you want to automate tests for an application, then it's exactly what you need. You have to control the GUI of another application through your test-software.

Answer 15

Ah, okay. Our end user application does not need that, as for driving user interface testing we are relying on 3rd party vendors for that.

Answer 16

Hi Dave,

I found that the element requestedPrivileges was introduced in urn:schemas-microsoft-com:asm.v3, not in the defaul asm.V1.  

So, the error probably is caused by the line <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> when it tries to get the reference for verison 3.

I am still working on the issue but unfortunately not good news yet.

Jason 
 

Answer 17

Hello,

If your application does not have a digital signature and has uiAccess=true in its manifest, it will fail with "A referral was returned from the server."

Applications that request uiAccess=true must have a valid, trusted digital signature to execute.

Also, applications by default must reside in a trusted location on the hard drive (such as windows or program files) to receive the uiAccess privilege. They will still run if they are not in one of these locations, but they will not receive the privilege. You can disable this security feature through the local security policy mmc snap-in.

If you want to create a trusted "test" certificate to sign your application with so that you can use your application on your current machine, here's how:

NOTE: These instructions assume you have visual studio installed and are using a command prompt that has all the environment variables set to find SDK utilities such as makecert and signtool. If not, you will need to find these tools on your hard drive before running them.

***

1) Open an elevated command prompt

- Click start
- Find Cmd Shell or command prompt
- Right-click, click Run As Administrator

2) Create a trusted root certificate

- Browse to the folder that you wish to contain a copy of the certificate
- In the command shell, execute the following commands:

    makecert -r -pe -n "CN=Test Certificate - For Internal Use Only" -ss PrivateCertStore testcert.cer

    certmgr.exe -add testcert.cer -s -r localMachine root

3) Sign your file

- In the command shell, browse to the location of your exe
- In the command shell, type:

SignTool sign /v /s PrivateCertStore /n "Test Certificate - For Internal Use Only" /t http://timestamp.verisign.com/scripts/timestamp.dll APP.exe

Where APP.exe is your application.

***

- JB
  Microsoft MVP - Windows Shell

Answer 18

This is just a wild guess, but it should be easy to check and discard if irrelevant.

I recall that at one point in the early XP days creating manifests strictly by hand there seemed to be "edge cases" where the manifest would fail if the source XML textfile was not an exact multiple of 4 bytes.  This could have been an issue with a funky resource compiler or something else, I can't recall now.

Quick to test though.  Just pad the file with blank spaces at the end if need be.  I still do it out of habit.

Answer 19

Hi Jimmy,

I cant get past stage 2. Like you have stated I input exactly  'makecert -r -pe -n "CN=Test Certificate - For Internal Use Only" -ss PrivateCertStore testcert.cer' but the 'testcert.cer' file is not created. I am in the correct folder, Command prompt prints out the following when I do this:

Usage: MakeCert [ basic|extended options] [outputCertificateFile]
Basic Options
 -sk  <keyName>      Subject's key container name; To be created if not present
 -ss  <store>        Subject's certificate store name that stores the output
                     certificate
 -sr  <location>     Subject's certificate store location.
                        <CurrentUser|LocalMachine>.  Default to 'CurrentUser'
 -#   <number>       Serial Number from 1 to 2^31-1.  Default to be unique
 -$   <authority>    The signing authority of the certificate
                        <individual|commercial>
 -n   <X509name>     Certificate subject X500 name (eg: CN=Fred Dews)
 -?                  Return a list of basic options
 -!                  Return a list of extended options

 

Can you tell me what I am doing wrong.

 

Thanks.

Answer 20

MFred wrote:

If you want to automate tests for an application, then it's exactly what you need. You have to control the GUI of another application through your test-software.

Not necessarily. You only need UIAccess=true if you need to automate elevated apps from apps running at a normal integrity level. It shouldn't be necessary if your app is running elevated already.

Answer 21

Hello,

It looks like you are using an old version of makecert. Try not including the -pe command line option.

- JB

Answer 22

Hi Jimmy,

 

Thanks alot that has sorted the problem of the creating the certificate. My application does work now.

My solution is still not perfect the reason being that my application is intended to many users who are not administrators this is problem because when the 'standard users' open the application they are requested for the administrator password, which I do not want them to have.

Therefore is there any way around this problem, where the standard users can execute the application without entering the admin password and also for the data to be written to the program files directory and not locally.

Your help will be appreciated.

MO1234

Answer 23

Hello,

Set your manifest so that the requested elevation level is either asInvoker or highestAvailable.

The first option will never ask for admin permission, even if the user is an administrator, and your program will not run with admin privileges.

The second option will only ask for admin permission if the user is an administrator; the program will be run without admin privileges (and without prompting) if the user is not an administrator; if the user IS an admin, the program will prompt and will run with admin privileges.

As for writing in program files; this operation is restricted to only allow Administrators to do this. While your setup program could modify this behavior, I cannot suggest for you to do this, as this is unacceptable behavior - the end result will be your application will create security vulnerabilities on the systems that install your app.

Programs that do not run with administrator privileges cannot perform administrator actions, such as writing in program files.

You need to find another place to store your data, such as (preferably) within the user's profile, or in the per-machine storage area (ProgramData in Vista, although you should use an API to retrieve this location, as opposed to hard coding it into your application).

If you could be more specific as to what you are needing to accomplish by writing to program files, I may be able to offer a more specific solution.

I would also like to make it clear that you will need to purchase a code signing certificate from a trusted third party (such as globalsign) and use it to sign your program if you want your application to work outside of your test environment.

Best of luck,

- JB

Answer 24

Hi Jimmy,

I've decided to use the Compatibility Administrator instead of a manifest. I have set my application executable to 'NoVirtualization', but when I run my application I get errors, specifically Registry errors as values can not be read in, otherwise if I run the application as an administrator then I do not get any Registry errors and the Application works fine.

Do you know how I could resolve this problem, more specifically what values can I set in the Compability Administrator, so that NoVirtulization can be set and for standard users to be able to use the application.

 

Thanks.

Mo1234

Answer 25

You shouldn't be having any problems READing registry data. Your application may be requesting to have full control when opening a registry key when it really only needs READ access. This will cause the open to fail if it is attempting to access something that is read-only, such as HKEY_LOCAL_MACHINE.

 

You need to specify in whatever API you are using to open the registry key/value that you only need read permission (or whatever specific permissions that you need); if you just use the default it probably requests full control, which you won't have in many cases when running as a standard user.

 

There really is no other solution available to you from a manifest/appcompat toolkit avenue. The problems you are experiencing now are cropping up due to your application not working correctly inside of a standard user account, and probably need to be fixed in your application.

 

As a guideline, any location on disk or in the registry that affects 1) more than one user or 2) the state of the system is read-only (requires administrator access to write to).

 

Your application will need to work correctly under those restrictions if it must work without requiring admin privileges.

 

- JB

Answer 26

Jimmy,

 

Thank you that has sorted out my problem with the registry keys.

 

I have come across another problem which I believe is the final hurdle to get past, its when my application runs it needs to open a database file (.mdb), this works fine when I run the application but an error occurs when I try to run the application as a standard user which is:

 

"Error 3051 The Microsoft Jet database engine cannot open the file "c:\myprogram\mydatabase.mdb". It is already opened exclusively by anoter user, or you need permission to view its data."

 

I know that application is not opened by another user, therefore it is a permission error. How can I resolve this problem? Is there a setting in the compatibility editor which I can set for my application?

 

Again thanks for your help and please can you answer this question as soon as possible.

 

M01234

Answer 27

Jimmy,

 

Its ok I managed to resolve the problem.

 

All I had to do was to change the security permissions on the program folders on my application to allow standard users to 'write' to the directory.

 

Thanks anyway.

Answer 28

That is an enormous security hole. Please don't do that under any circumstances.

 

You can fix your issue by storing the database in a subdirectory of CSIDL_COMMON_APPDATA  and allowing the Users group Modify permissions on that file.

Answer 29

Mo1234 wrote:

Jimmy,   Its ok I managed to resolve the problem.   All I had to do was to change the security permissions on the program folders on my application to allow standard users to 'write' to the directory.   Thanks anyway.

 

Hello,

 

As Andy said, doing this makes the system extremely insecure.

 

If this is a computer that you own or are responsible for, then doing this is of course your decision to make.

 

However, if you are distributing your application to others and intend to do this on any computer that installs your application, this is unacceptable.

 

You MAY NOT change security permissions on system folders, even though it may be technically possible to do so.

 

The better solution is to do what Andy suggested, use the appropriate folder to store your data (ProgramData in Vista, accessible via the ID that Andy mentioned from the SHell API's) and then if necessary, change the permissions on only the file(s)/folders that YOU CREATED (not system files).

 

I should also include, it is unacceptable to change permissions on your program's folder in programfiles, or really anything in programfiles, *especially* executable files.

 

- JB

Answer 30

I have a directory like C:\CompanyTools on my users computer for inhouse tools and logfiles. I changed the acls on Vista machines so the logfiles can be written to it. It doesn't follow vista convention but why does it make it extremely insecure. This folder is not a system folder.

There are too many tools and dependencies at our place to start moving it around into Program Files and ProgramData. In a mixed environment with xp and vista it creates unneeded complexity by having two different folder structures.

Answer 31

Jimmy and Andy,

 

The folder permission I change is my applications folder not the program files folder, i.e. c:\program files\myapp

 

I do not have much of an alternative but to change the security settings as I do not want to have virtualization set for my application therefore my application data needs to be written somewhere which under XP is the application program folder. Also I would have to overhaul my code quite significantly in order to get it writting to the app data, therefore to much problems hence this is the way application will have to function under vista.

 

I got a question regarding writing to registry. When I set the 'NoVirtualization' option on my application it can read from registry i.e. when I use KEY_READ but when I try to write to registry using KEY_WRITE nothing happens which again is a permission thing.

 

What can I do to read/write/set key values in registry as a standard user i.e. what keys can I use.

 

By the way I want to write to HKEY_LOCAL_MACHINE.

Answer 32

By the way you guys should check out this article:

 

http://support.microsoft.com/kb/927387

 

Paticularly scenario 4.

Answer 33

Jack Daniel wrote:

I have a directory like C:\CompanyTools on my users computer for inhouse tools and logfiles. I changed the acls on Vista machines so the logfiles can be written to it. It doesn't follow vista convention but why does it make it extremely insecure. This folder is not a system folder.

 

That's not quite so bad, though if you have Standard Users and store executables in that directory then you have potential privilege escalation attacks. It should also be noted here that there is a major difference between making these sorts of changes on your own company's machines where you can weigh up the potential risks and doing it as part of a generic application installation that potentially opens a security hole in other peoples computers.

Answer 34

Mo1234 wrote:

Jimmy and Andy,   The folder permission I change is my applications folder not the program files folder, i.e. c:\program files\myapp

 

It doesn't matter, all of Program Files and it's subdirectories form a 'Trusted Location', being able to change executables there not only allows for Standard User privilege escalation attacks but also potentially allows further escalation via the uiAccess flag.

 

Mo1234 wrote:

I do not have much of an alternative but to change the security settings as I do not want to have virtualization set for my application therefore my application data needs to be written somewhere which under XP is the application program folder. Also I would have to overhaul my code quite significantly in order to get it writting to the app data, therefore to much problems hence this is the way application will have to function under vista.

 

It is no more correct to use the applcation's Program Files folder under XP than it is Vista, you are just more likely to get away with it. You should obtain the correct location for shared data by passing CSIDL_COMMON_APPDATA to the shell APIs such as ShGetSpecialFolder. Under XP this will direct you to somewhere like "C:\Documents and Settings\All Users\Application Data" and on Vista to the ProgramData folder, where it is safe to create a directory with appropriate permissions. By storing only data, not executables, here you block potential avenues for privilege escalation.

 

Mo1234 wrote:

What can I do to read/write/set key values in registry as a standard user i.e. what keys can I use.   By the way I want to write to HKEY_LOCAL_MACHINE.

 

Standard Users should preferably write to HKEY_CURRENT_USER - allowing them to make modifications to global settings under HKLM is generally a bad idea since their changes can negatively impact on other users. If you absolutely must allow them to make global changes then you should isolate the settings from other global settings they shouldn't change and set permissions appropriately.

 

For the record, "appropriate permissions" should usually be limited to Read/Write access for the Users group only. Do not grant Full Control (since this allows circumvention of ACLs and/or Auditing settings) and do not grant permission to the Everyone group (since this potentially covers Anonymous Access)

Answer 35

I have made one application and trying to run in Windows Vista 32 bit Business edition. When I run normally that is working fine but if i run as "Run as Administrator", iam getting the error "A referral was returned from the server". Could any one please tell me the reason?

 

With Regards

Kumar.M

 

Answer 36

Does anybody know the reason?

Answer 37

I got the issue and solved it...thanks

 

With Regards

Kumar.M

 

Answer 38

 

I got this:

 

Splitted
VCDetect is unable to set the environment.
Setting SDK environment relative to C:\Program Files\Microsoft SDKs\Windows\v6.0
.
Targeting Windows XP x86 DEBUG

C:\Program Files\Microsoft SDKs\Windows\v6.0>makecert -r -pe -n "CN=Test Certifi
cate - For Internal Use Only" -ss PrivateCertStore testcert.cer
Error: Can't create the key of the subject ('0370882d-102c-4412-a958-3674315402d
a')
Failed

C:\Program Files\Microsoft SDKs\Windows\v6.0>

 

 

Is there no answer for this?

Answer 39

Hi

Iwrite a program in visual basic 6.0. This program has access 2003 database. I use DAO 3.6 to connect database.

My program works in XP perfectly but I have same problem in Windows vista. How can i solve this problem?

 

"Error 3051 The Microsoft Jet database engine cannot open the file "c:\myprogram\mydatabase.mdb". It is already opened exclusively by anoter user, or you need permission to view its data."

The mdb file is not a readonly file.

 

Thanks for your help.

Answer 40

1. Check to see if your current user is part of the Administrators group.

 

Restart in Safe Mode (F8) with command prompt

 

Type in net localgroup administrators

 

See if your name is listed.

 

2. Check in registry at HKLM/Software/Microsoft/Windows/CurrentVersion/Polices/System

 

Make sure the ValidateAdminCodeSignatures entry is set to 0. If it is set to 1 than any piece of software (that includes drivers) that are digitally unsigned will be denied access with following "Referral returned to server" prompt.

 

If you can't access registry (because you are given same "referral returned to server" prompt) copy the following registry code in notepad and save as ValidateAdminCodeSignatures.reg

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"ConsentPromptBehaviorAdmin"=dword:00000002
"ConsentPromptBehaviorUser"=dword:00000001
"EnableInstallerDetection"=dword:00000000
"EnableLUA"=dword:00000001
"EnableSecureUIAPaths"=dword:0000000
"EnableVirtualization"=dword:00000000
"PromptOnSecureDesktop"=dword:00000001
"ValidateAdminCodeSignatures"=dword:00000000
"dontdisplaylastusername"=dword:00000000
"legalnoticecaption"=""
"legalnoticetext"=""
"scforceoption"=dword:00000000
"shutdownwithoutlogon"=dword:00000001
"undockwithoutlogon"=dword:00000001
"FilterAdministratorToken"=dword:00000000
"EnableUIADesktopToggle"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\UIPI]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\UIPI\Clipboard]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\UIPI\Clipboard\ExceptionFormats]
"CF_TEXT"=dword:00000001
"CF_BITMAP"=dword:00000002
"CF_OEMTEXT"=dword:00000007
"CF_DIB"=dword:00000008
"CF_PALETTE"=dword:00000009
"CF_UNICODETEXT"=dword:0000000d
"CF_DIBV5"=dword:00000011

 

 

3. Activate hidden administrator account in Vista, reboot in safe mode, log in under Administrator and disable UAC.

 

Open commmand prompt, type in net user administrator /active:yes

 

Restart in safe mode (F8)...

 

Log in under default administrator account, go into control panel, blah blah, disable user account control. An idiot solution but it might just work.

Answer 41

THANK GOD You had This answer:...

Make sure the ValidateAdminCodeSignatures entry is set to 0. If it is set to 1 than any piece of software (that includes drivers) that are digitally unsigned will be denied access with following "Referral returned to server" prompt.

 IT WORKED MAN! i have had this issue ALL FRIGGIN' Day (On PC trying to figure it out for over 7 hours LOL (No joke!!) Your answer was the ONLY

valid and to the point solution that resolved this issue immediately, I cannot believe the path others took to try to fix this exact problem, WOW make one's head spin with all the codes and crud to go through to no avail. Anyway many paths to the root of a soultion yes indeed, just like all roads lead to nashville (well at least U.S.A.'s roads... ok so bless YOu tenfold bro, I am relieved and blessed by Your input!!!

 

NecroGnomezZz...-=+<(____)~CheerzZz...!

 

StanDP.

 

Press ENTER to look up in Wiktionary or CTRL+ENTER to look up in Wikipedia
<input id="QuickWikiInput" class="QuickWiki" type="text" />

Answer 42

Thank you so much man.

I had programs that worked until about a week ago.

I'm running win7 home premium & the programs are (x86) with my system being (x64).

I have no idea how, what or why that registry key was changed but after using your input, they now work again :) & even ask for approval with uac activated.

 

thanks again to You & all the others out there that have (or make) the time to figure this stuff out.

Answer 43

Hi,

As Jimmy said, I am able to sign my WPF exe by following the steps.

1) Open an elevated command prompt
- Click start
- Find Cmd Shell or command prompt
- Right-click, click Run As Administrator
2) Create a trusted root certificate
- Browse to the folder that you wish to contain a copy of the certificate
- In the command shell, execute the following commands:
  makecert -r -pe -n "CN=Test Certificate - For Internal Use Only" -ss PrivateCertStore testcert.cer
  certmgr.exe -add testcert.cer -s -r localMachine root
3) Sign your file
- In the command shell, browse to the location of your exe
- In the command shell, type:
SignTool sign /v /s PrivateCertStore /n "Test Certificate - For Internal Use Only" /t http://timestamp.verisign.com/scripts/timestamp.dll APP.exe
Where APP.exe is your application.

But when i try to build my Setup Project, the exe is losing its signature or recreated without the signature.

Please help me how to make sure that the signed exe is added in the setup file.

 

---

Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This will help other members to find the solution easily.