none
Manifest files for Vista

    Question

  • Hi,

    For some of the exes of my product, I need administrative privilege. So I embed them in my application with "requireAdministrator". It works fine on Windows Vista and prompts for allow/deny or administrator uname/password as applicable.

    But the same program has non consistent performance on previous OS versions(XP, 2003 Small business etc). It shows blue screen sometimes for the applications where these manifest files are embedded. One can avoid these blue screens if the embedded manifest file is also present in the same directory as the exe for other OS.

    I do not want to make my application dependant on the presence of manifest file in the same directory. Is there a way out? Is there a tool to find whether an embedded manifest file will work or not on all previous OS.

    Is there any other way to achieve the elevation on Vista? Or is it better to have different set of exe for Vista?

    Thanking you in advance,

    Vikash

     

    Friday, June 09, 2006 11:39 AM

All replies

  • This is strange, I have no problems with running the executables containing Vista "elevation" manifests on former OS and I don't have manifest files in the directory.

    My manifests look like this:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly
       xmlns="urn:schemas-microsoft-com:asm.v1"
       manifestVersion="1.0">
    <assemblyIdentity
        processorArchitecture="x86"
        version="5.6.0.0"
        type="win32"
        name="elevcc.exe"/>
        <description>Control Center Elevation Launcher</description>
        <dependency>
        <dependentAssembly>
        <assemblyIdentity
             type="win32"
             name="Microsoft.Windows.Common-Controls"
             version="6.0.0.0"
             publicKeyToken="6595b64144ccf1df"
             language="*"
             processorArchitecture="x86"/>
        </dependentAssembly>
        </dependency>
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel
              level="requireAdministrator"
              uiAccess="false"/>
            </requestedPrivileges>
           </security>
      </trustInfo>
    </assembly>

    If I read it correctly from our build script, then we are using the following command to embed the manifest into executables:

    mt -nologo -manifest file.manifest  fullpath.file.exe -outputresource: fullpath.file.target.exe;id

    where id is 1 for exe's and 2 for dll's.

    Maybe you should also check if you are using the latest version of mt utility (from the latest SDK), although I think that this shouldn't actually matter.
    Monday, June 12, 2006 11:35 AM
  • Hi All,

    I also met the same problems that  my embedded manifest EXE file leads OS blue screen.

    My Dev tool is VS8 Pro.

    This is my manifest:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <assemblyIdentity version="7.95.0.0"
         processorArchitecture="X86"
         name="TScan"
         type="win32"/>

      <description>T Scan</description>
      <!-- Identify the application security requirements. -->
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel
              level="asInvoker"
              uiAccess="true"/>
            </requestedPrivileges>
           </security>
      </trustInfo>
    </assembly>

    Are there any wrong items in this manifest?

    Are there any solutions to fix this problems?

    Best regards,

    Jesse Wang.

    Monday, June 12, 2006 3:07 PM
  • My manifest file is as below

    <?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="MyApp"
         type="win32"/>

    <dependency>
       <dependentAssembly>
         <assemblyIdentity
           type="win32"
           name="Microsoft.Windows.Common-Controls"
           version="6.0.0.0"
           processorArchitecture="X86"
           publicKeyToken="6595b64144ccf1df"
           language="*"
         />
       </dependentAssembly>
    </dependency>
      <description>This application is used to give higher security permissions to other users</description>
      <!-- Identify the application security requirements. -->
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel
              level="requireAdministrator"
              uiAccess="false"/>
          </requestedPrivileges>
        </security>
      </trustInfo>
    </assembly>

    For this manifest file, if it is not present in the same dir on Win 2003 svr, it crashes while starting. I have other one simpler as the one Jesse has posted. In that case the application comes up but shows blue screen somewhere in one of the use cases of application.

    Do we mandatorily need to put all the dependent assembly information? Is there a easier way to test the problems with manifest file?

    TIA,

    Vikash

    Tuesday, June 13, 2006 9:41 AM
  • On Windows XP (Home & Pro), I'm actually getting full OS crashes/reboots when using the trustinfo structure/manifest, and starting an application more than once (when compiling with VS 2005) ...

    Try this hello-world app (crashme.c):

    #include <windows.h>
    #include <stdio.h>

    int main()
    {
        prinf("Hello World!\r\n");
        while(1)
            Sleep(1000);
        return(0);
    }


    Compile that as a console application (crashme.exe)  ...
    Then we need to merge the trustinfo manifest, so create a file named  crashme.exe.manifest  :

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

    Then let's merge this manifest with the one that Visual Studio 2005 already embedded:

    mt.exe -inputresource:crashme.exe;#1 -out:extracted.manifest
    mt.exe -manifest extracted.manifest crashme.exe.manifest -out:merged.manifest
    mt.exe -outputresource:crashme.exe;#1 -manifest merged.manifest

    Then start up the program 2-3 times and your entire computer will reboot. (note this only seems to happen when you have multiple copies running, though if you have 2 different applications, e.g. you made a crashme2.exe, you can get it to happen by running that executable while crashme.exe is running).
    I'm not sure if this is reproducable on any other versions of Windows, it doesn't appear to happen on Windows 2003 R2 x64 ...

    Anyone have any suggestions to prevent this?  I've tried including the manifest file with the executable as suggested here, but it still crashes.

    -Brad

    Tuesday, June 27, 2006 3:32 PM
  • Try this for a workaround (solution comes secondhand from Microsoft):

    Open your project in VS
    Under project , Select properties:
    Go to manifest tool->Input and Output
    Remove any entry you have in the Additional manifest files line.
    Rebuild the app.

     At this point, you should have your app with only the default manifest that VS installs.  It should not contain the trustInfo statements…
    Now we’re going to manipulate the manifest in the .exe directly using a tool called mt.exe that comes w/ VS 2005
    From a command prompt, extract the current manifest from the file.

                    mt.exe –inputresource:(yourapp).exe;#1 –out:temp.manifest

    Open temp.manifest with an text editor like notepad.  It may look something like this:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
    </assembly>

    The important thing to note is that these should be no trustInfo statement in this manifest at this time.
    Now we’re going to insert the trust info into this manifest.  It should then look something like this:
     

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>
        </dependentAssembly>
      </dependency>

    <!-- Identify the application security requirements. -->
       <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
          <security>
          <requestedPrivileges>
            <requestedExecutionLevel
              level="requireAdministrator"
              uiAccess="false"/>
          </requestedPrivileges>
        </security>
       </trustInfo>

    </assembly>

    Note: make sure you use <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">  instead of .v3

    Use mt.exe to insert this new manifest into the file.
                    mt.exe –manifest temp.manifest –outputresource:(Yourapp).exe;#1

    You should be able to run this file on both Vista and XP.

    Once you get it to work manually you should be able to script the changes for automated building.

    Tuesday, July 25, 2006 3:44 PM
  • Microsoft has finally published the fix for the blue screen crashes in Windows XP caused by Windows Vista manifests:

     

    http://support.microsoft.com/Default.aspx?kbid=921337

    • Proposed as answer by John L Veazey Saturday, July 16, 2011 8:01 AM
    Tuesday, July 25, 2006 4:29 PM
  • The only relevant info I was able to get out of the previous post (by Adrian) was to use
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> instead of
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    Please note that this does NOT correct the situation, though it does slightly
    change the outcome by locking the entire computer instead of rebooting, but
    I've heard changing other contents of that manifest can alter the behavior as well
    (e.g. BSOD), so it really doesn't mean much.

    I think the true fix must come from microsoft, and that KB921337 is a good sign,
    hopefully they'll release it to the general public via Windows Update with enough
    time that most computers will be patched prior to Vista release (especially since if
    you can modify the behavior via the manifest, you might be able to exploit this to
    gain additional privileges).

    -Brad
    Tuesday, July 25, 2006 4:55 PM
  • In VS 2005, the c/c++ IDE interface that permits the inclusion of additional manifest files in the target .exe does some processing on the XML and inserts a duplicate xmlns tag.  This duplicate tag exacerbates an XP schema parsing bug resulting in a crash on XP.   Because of this, the previously documented method on how to include a manifest in a Visual Studio 2005 c++ project cannot be used if it is desired that the file run on Windows XP also.  In general , the manifest needs to be modified in two ways.

     

    1)    A schema version of 2 should be used instead of 3 in the trustInfo section

    2)    The additional xmlns field in the trustInfo section needs to be removed.  See Example A.

     

    Example A:

     

    <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2" xmlns="urn:schemas-microsoft-com:asm.v2">

     

    Should be this:

     

    <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">

     

    Updated procedure

     

    Although a patch is planned for Windows XP to correct the XML parsing bug, developers need a way to deploy the same build of the application on both Windows XP and Windows Vista without relying upon this fix.  The procedure described below will permit this scenario.  

     

    A fix is also planned for the mt.exe tool to address the problem where it generates mal-formed XML.  Until a new version of mt.exe is available, the current version can still be used, but in only in q manner where the merge feature is not used.

     

    If you are not using Visual Studio, you basically just need to change the version number in the trustInfo line of the manifest from v3 to v2.  If you are using Visual Studio 2005, follow the steps outlined below.

     

    c/c++ project type:

     

    Open your project in VS

    Under project, Select properties:

    Go to manifest tool->Input and Output

    Remove any entry you have in the Additional manifest files line.

    Rebuild the app.

     

    At this point, you should have your app with only the default manifest that VS installs.  It should not contain the trustInfo statements…

     

    Manipulate the manifest in the .exe directly using mt.exe.  mt.exe is included with Visual Studio.  From a command prompt, extract the current manifest from the file.

     

            mt.exe –inputresource:YourApp.exe;#1 –out:temp.manifest

     

    Open temp.manifest with an text editor like notepad.  It may look something like this:

     

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

        </dependentAssembly>

      </dependency>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

        </dependentAssembly>

      </dependency>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>

        </dependentAssembly>

      </dependency>

    </assembly>

     

    Now we’re going to insert the trust info into this manifest using a text editor like notepad.  It should then look something like this:

     

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

        </dependentAssembly>

      </dependency>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

        </dependentAssembly>

      </dependency>

      <dependency>

        <dependentAssembly>

          <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="x86" publicKeyToken="6595b64144ccf1df" language="*"></assemblyIdentity>

        </dependentAssembly>

      </dependency>

     

       <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> 

          <security>

            <requestedPrivileges>

              <requestedExecutionLevel

                level="asInvoker"/>

            </requestedPrivileges>

          </security>

       </trustInfo>

     

    </assembly>

     

    Note: make sure you use <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">  instead of .v3

     

    Use mt.exe to insert this new manifest into the file.

     

                    mt.exe –manifest temp.manifest –outputresource:YourApp.exe;#1

     

    You should now be able to run your executable on both Vista and XP.

     

     

    Managed code (c#, j# and VB)

     

    Visual Studio does not currently embed a default manifest into managed code.  For managed code, the developer would simply insert a default manifest into the target .exe using mt.exe.  The steps would be as follows:

    1.     Use a text editor like notepad to create a default manifest file, temp.manifest.  Here is a default manifest that can be used as a sample.

     

      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

      <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

          <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">

              <security>

                   <requestedPrivileges>

                       <requestedExecutionLevel

                           level=”asInvoker”/>

                   </requestedPrivileges>

              </security>

          </trustInfo>

      </assembly>

     

     

    2.     Use mt.exe to insert the manifest.  The command would be:

     

    mt.exe –manifest temp.manifest –outputresource:YourApp.exe;#1

    Tuesday, July 25, 2006 5:46 PM
  • You're right, the second xmlns that mt.exe generates is what appears to cause
    the issue.  Luckily I have cygwin on that box with sed, and can still script out
    the release, as doing that manually would be a pain.  Hopefully M$ can push
    a fix for both bugs out soon.
    Tuesday, July 25, 2006 7:30 PM
  • You might also want to manipulate the manifest in the .exe directly with Resource Tuner from http://www.restuner.com
    Thursday, July 27, 2006 3:42 PM
  • Hi, I've prepared a small script to add into post-build event.

    the typical comand line looks like: cscript  //B "$(SolutionDir)patchmanifest.js" "$(TargetPath)" "$(ProjectDir)res\description.manifest" "$(ProjectDir)res\indent.xsl"

    description.manifest content:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <description>YourAppName Application</description>

    <!-- Identify the application security requirements. -->
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
      <security>
        <requestedPrivileges>
          <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>
        </requestedPrivileges>
      </security>
    </trustInfo>
    </assembly>

    patchmanifest.js content:

    XMLVER = "Msxml2.DOMDocument.3.0";

    var oArgs = WScript.Arguments

    if (oArgs.length < 2)
    {
        WScript.Echo("Usage: patchmanifest app.exe patch.manifest [stylsheet]");
        WScript.Quit(1);
    }

    try
    {
        var Shell = WScript.CreateObject("WScript.Shell");

        var oExec = Shell.Exec("mt.exe -nologo -out:$tmp.manifest -inputresource:\"" + oArgs(0) + "\"");

        while (oExec.Status == 0) { WScript.Sleep(100); }

        if (oExec.Exitcode != 0)
        {
            WScript.Echo("Manifest Tool error");
            WScript.Quit(2);
        }


        var xml = WScript.CreateObject(XMLVER);

        xml.async = false;
        xml.load("$tmp.manifest");


        var pat = WScript.CreateObject(XMLVER);

        pat.async = false;
        pat.load(oArgs(1));

        var node = pat.documentElement;
        while (node.hasChildNodes())
        {
            xml.documentElement.appendChild(node.firstChild);
        }

        if (oArgs.length > 2)
        {
            var xsl = WScript.CreateObject(XMLVER);

            xsl.async = false;
            xsl.load(oArgs(2));

            var out = WScript.CreateObject(XMLVER);

            out.async = false;
            out.validateOnParse = true;

            xml.transformNodeToObject(xsl, out);
            out.save("$tmp.manifest");
        }
        else
        {
            xml.save("$tmp.manifest");
        }

        Shell.Exec("mt.exe -nologo -manifest $tmp.manifest -outputresource:\"" + oArgs(0) + "\"");

        WScript.Quit(0);
    }
    catch (e)
    {
        WScript.Echo("ERROR:", e.name, "-", e.description);
    }

    and another one is patchmanifest.vbs

    Const XMLVER = "Msxml2.DOMDocument.3.0"

    On Error Resume Next

    Set oArgs = WScript.Arguments

    if oArgs.Count < 2 then
       
        WScript.Echo "Usage: patchmanifest app.exe patch.manifest [stylsheet]"
        WScript.Quit 1
    end if

    Set Shell = CreateObject("WScript.Shell")

    Set oExec = Shell.Exec("mt.exe -nologo -out:$tmp.manifest -inputresource:" & Chr(34) & oArgs(0) & Chr(34))

    do while oExec.Status = 0

         WScript.Sleep 100
    loop

    if oExec.Exitcode <> 0 then

        WScript.Echo "Manifest Tool error"
        WScript.Quit 2
    end if


    Set xml = CreateObject(XMLVER)

        xml.async = false
        xml.load "$tmp.manifest"


    Set pat = CreateObject(XMLVER)

        pat.async = false
        pat.load oArgs(1)

    Set node = pat.documentElement


    do while node.hasChildNodes

        xml.documentElement.appendChild(node.firstChild)
    loop


    if oArgs.Count > 2 then

    Set xsl = CreateObject(XMLVER)

        xsl.async = false
        xsl.load oArgs(2)

    Set out = CreateObject(XMLVER)

        out.async = false
        out.validateOnParse = true

        xml.transformNodeToObject xsl, out
        out.save "$tmp.manifest"
    else
        xml.save "$tmp.manifest"
    end if

        Shell.Exec("mt.exe -nologo -manifest $tmp.manifest -outputresource:" & Chr(34) & oArgs(0) & Chr(34))

        WScript.Quit 0

    if Err <> 0 then
        WScript.Echo ""
        WScript.Echo "Error:", Hex(Err.Number), "-", Err.Description
        Err.Clear
    end if

    Thursday, September 07, 2006 5:22 AM
  • Another workaround is to copy the newer version of mt.exe from <VS2005 root folder>\Common7\Tools\Bin  into the <VS2005 root folder>\VC\bin folder.

    The newer mt.exe (version is 6.0.4071.0) does not create the malformed manifest that the older version (version is 5.2.3790.2075) does.  Obviously having a correct manifest does not crash/hang XP any more and with new trustinfo there you get proper UAC interaction on Vista. 

    The same three mt.exe shipped in VS2005 so this solution existed from the beginning.

    Side note: <VS2005 root folder>\SDK\v2.0\bin also contains the same older mt.exe version (5.2.3790.2075).

     

    Wednesday, October 04, 2006 3:43 PM
  • SP1 beta does not resolve this problem with mt.exe

    so, the best workaround i know  is just to delete $(VCInstallDir)bin\mt.exe :)

    Wednesday, October 04, 2006 5:43 PM
  • Right SP1 does not fix this problem -- I came across the extra "newer" mt.exe while attempting to determine whether or not mt.exe was updated at all in the SP1 beta MSP.  It's then that I found out there were actually three mt.exe files and noticed that one was newer.

    If you simply delete the VC/bin version of mt.exe be aware that repairing/patching VS2005 will cause it to come back.  It's better to copy the newer version overtop to prevent the old version from being used by accident.

    Wednesday, October 04, 2006 7:10 PM
  • I've checked the newest information on Vista manifests available in various articles/files at http://msdn.microsoft.com/windowsvista/ . Some of them use  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> and some - <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> .

    It seems that both v2 and v3 statements should work in Windows Vista and Windows XP (if duplicate xmlns isn't specified).

    So it's not clear which version to use in applications for Windows Vista. It's quite strange that while Vista is already RTMed there is still no final documentation on how to build applications for Vista.

    Does anybody have additional information on this issue? Is there any difference between v2 and v3 used in manifests?
    Monday, November 13, 2006 5:24 PM
  • I made a simple app and test both solutions. To me, both solutions work just fine:

    1. keeping the trustInfo .v3 and using the newer mt.exe (version 6.0.4071.0), or
    2. changing the trustInfo into .v2 and using with any version of mt.exe

    Thanks for all suggestions.
    Tuesday, November 21, 2006 10:56 PM
  • Hi Guys!

    Have you actually embedded manifests to visual foxpro exe and they run fine?

    I have a simple manifest, does not require administrator (testing at the mo) and going as invoker. Basiaclly embedding the manifest currupts the exe and foxpro first prompts for a file to run (defaults to .fxp extension) and when I re-open the "manifested" exe, it complains that "it is not a visual foxpro .EXE"

    Here is the manifest:

    <?xml version="1.0" encoding="utf-8" ?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="sales order processing" type="win32" />
      <description>sales order processing</description>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" />
          </requestedPrivileges>
        </security>
      </trustInfo>
    </assembly>

    I tried not use sop throughout instaed of the long file name. It made no difference.

     

    Any clues? And what version of mt.exe are you using?

     

    Regards

    Mathias

    Wednesday, January 03, 2007 11:32 AM
  • Have you been able to get this to work for a visual foxpro exe?

     

    Thanks

    Ashish

    Thursday, February 22, 2007 11:55 PM
  • Well,

    Other OSes (example WinXP) does not recognise the exe, treats it as if it was corrupt. For other os(es) leave the exe without the manifest. So basically you want to ship 2 executables. And let the installation install the appropriate one depending on whether or not its Vista.

    I am not aware of another way to achieve elevation apart from the manifest route. But there are other ways of adding the manifest. In .NET you can configure your project to automatically embed a manifest after building. I suppose you could achieve that in VFP by running a script in the post-build project event. I will try that.

    Regards

    Mathias

    Friday, February 23, 2007 2:27 AM
  • Thanks Mathias. I was just looking into embedding a manifest into a Visual FoxPro exe. for compliance with a vista certification requirements. I can use ml.exe to embed it in the exe, which I can confirm with the CFF Explorer app. However the exe gets corrupted as its reported size is only 32kb while it used to be 13000KB. I do not understand what is happening.

    An external manifest seems to work fine so I'll stick to that for now.

    Regards

    Ashish

    Friday, February 23, 2007 6:00 PM
  • Hi.

     

    Were you ever able to embed an application manifest into a VFP executable.  I am having the exact same problem that you describe.  When I use an external manifest and set the requestedExecutionLevel to "asInvoker", it does not disable virtualization for the application.  Any help is appreciated.  Thanks.

     

    Florence

    Wednesday, February 28, 2007 9:35 PM
  • It looks like that VFP's EXEs have two parts: a first part (at the beginning) which acts as a loader, and a second part which is your Fox application.
    From what I can see, the second part is just appended; then the EXE simply executes what finds after itself. Probably the loader is something self-contained, so it doesn't know much about the following fox app, besides the starting point.
    The trouble is there: when you apply a manifest using mt.exe, it checks for the EXE header and does not see the second (big!) part of your file. So it updates the exe stub but then cuts of the file at the end of the first part.
    So far I've found no way to specify a manifest inside VFP9's IDE, but I hope that the next Fox releases will provide that.
    My guess is that you should be able to split your EXE in two halves, attach the manifest to the first one, and the append the second one..

    As of the v2/v3 issue, so far I've been using the v3 version in my manifests and it seems to work. I didn't use the two namespaces because I read about the crash possibilitiy in this KB page.

    Hope this helps!
    Luke
    Thursday, March 01, 2007 9:55 AM
  • Hi All,

                We have an application installer that adds an add-in with outlook. And during this process we invoke some Exec’s during our installation from installer. But any changes done by these Exec’s are not reflected on Outlook. The same Exec’s work just fine when copied to the desktop and run from there.

    As per some of the suggestions in this post, we included the manifest information in our Exec’s using the “mt.exe” also changed the name of the Exec’s to start with "Setup". Then tried running the updated installer with these Exec’s on a Vista machine. Very changes made by the Exec’s seem to be getting reflected properly.

    But them all of a sudden every thing started giving error. OL won’t start and all the programs were lost. In short all the data from Vista was lost and on trying to restart the machine, it gave error that windows is corrupted please insert CD to repair it. And reported an error with a file named something like intelide.sys.

    Regards,
    Huzaifa
    Friday, March 02, 2007 1:16 PM
  • I don't know what may be causing your system to crash so badly, but I would like to point out something that could help your understanding what is appening to your application.
    You've surely heard that Vista has a new feature called "Virtualization". If an application doesn't have a manifest, your brand-new OS will try to do the best it can for letting your legacy application work.
    To be short, if your application tries to write in a protected area and it does not have a manifest, it gets "virtualized": the OS will redirect writes from the protected files to a writable copy it makes "on the fly", placing it in an area for which the user has write permissions. Beware that in this way different users will then "see" different files, so if you application writes to a config file under its installation folder, changes made by user1 will not be seen by user2, if virtualization is being used.
    When you add a manifest, however, your application stops being virtualized. That way you'll get errors instead of the silent copy-on-write redirections. You should be aware of that.
    I don't know precisely if those files that were virtualized will be discarded or if they will be shown to their respective owners instead of the "real" ones. I think the latter scenario is more likely to be the right one, but I'll have to double-check it.
    The correct solution is to place your files in the right position, so you'd better not place user-changeable files below %programfiles% or %windir%, for instance...
    In this respect MSDN is a great place to look into (sometimes even too great :)).

    HTH

    Saturday, March 03, 2007 12:29 AM
  • I've just been reading through this thread because we have a set of applications in which we want to disable virtualization, and, after reading the MSDN information on virtualization it became apparent that we could do so by specifying a requiredExecutionLevel value in our manifests.

    We merge the manifest file which the compiler produces with a 'standard' manifest file that contains the trustInfo information in (and receive the annoying authoring warning 81010002 into the bargain - which I understand is meant to be fixed in SP1?) using mt.exe (6.0.4071.0) and this seems to produce correctly formatted manifest files...

    ...However I have 2 applications, both of which (because they have the same runtime dependencies) have the same manifest file content:-

     <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
      <dependency>
        <dependentAssembly>
          <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        </dependentAssembly>
      </dependency>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
          </requestedPrivileges>
        </security>
      </trustInfo>
    </assembly>

    In one of these two applications, Virtualization is disabled, in the other, it's enabled - this is what task manager is telling me anyway.

    It looks like a bug to me - because I cannot fathom why the two applications are being treated differently given that they are using the same content (although one manifest is called program1.exe.manifest, the other is called program2.exe.manifest - the text inside is identical).

    Anyone have any experience of this? It's the inconsistency I find most disconcerting.

    Wednesday, March 14, 2007 7:05 PM
  • Hi, ice88

    Your manifests looks ok to me, but your last sentences left me a doubt: from what you say, you seem to be using external manifests, that is a couple of files consistently named which contains your manifests' xml information.
    Have you checked if your executables (one of them, at least, the one still having virtualization enabled) contain an embedded manifest?
    I think that, if an exe has its own manifest embedded in it, that will "hide" the external one (why search for something you already have? - I guess)
    You can easily check it:
    - using CFF Explorer, for instance, and looking for manifests among the EXE's resources
    - using mt.exe to extract the EXE's manifest, if it has one
    - using another resource explorer (there are many out there that show or edit PE resources)

    Once you know what you have in it, you can "merge" those two - or simply embed the one you need into the exe file. As far as I know, there are some situations in which an external manifest is not considered, so in my opinion you'd better place it inside...

    As you probably know, the same mt.exe tool that you're using to merge the manifests can be employed to embed them into the exe file. I don't have an example at hand for that, but if you need one, all you have to do is to ask ;)

    HTH
    Thursday, March 15, 2007 12:00 AM
  • Hi Luke,

    I can see why the statement in my previous update left you in some doubt, I'll clarify the situation.

    I actually embed the merged manifest into the executable, in the runtime environment on Vista there are no external manifest files.

    The names I was referring to 'program1.exe.manifest' and 'program2.exe.manifest' are the manifest files which look like the previous post, I then embed them into the exe using:

    mt.exe -nologo  -manifest program1.exe.manifest -outputresource:program1.exe;#1

    mt.exe -nologo -manifest program2.exe.manifest -outputresource:program2.exe;#1

    I took your advice and picked up a copy of CFF Explorer to look at the two exe's resources it shows (literally cut and pasted - so sorry about the formatting):-

    program1:

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity></dependentAssembly></dependency><trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">

    <security>

    <requestedPrivileges>

    <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>

    </requestedPrivileges>

    </security>

    </trustInfo></assembly>

    program2:

    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity></dependentAssembly></dependency><trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">

    <security>

    <requestedPrivileges>

    <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>

    </requestedPrivileges>

    </security>

    </trustInfo></assembly>

    As you can see, they're identical, but with them set this way, program2 has virtualization disabled (which is what I want) but program1 has virtualization enabled (which I don't want).

    Just to re-iterate, there are no external manifest files on the Vista machine.

    Thursday, March 15, 2007 9:13 AM
  • Thank you for clarifying :)
    There is a thing I'm asking myself in these days: should we use urn-schemas-microsoft-com:asm.v2 or urn-schemas-microsoft-com:asm.v3?
    I still don't know precisely what's the difference, if any.
    Anyway I'm using the v3 version: I looked at Vista's WordPad and it has the same namespace, so I thought that it would be ok.
    I wish to suggest you a test: have you tried using the requireAdministrator level?
    I mean, not in your final application, only once, for testing: try changing that to assure that Vista is actually using the settings you put into the manifest. If it does, you should see the elevation prompt; if not, your exe should be launched without further notice.
    (I'm obviously assuming you are not launching your apps from an elevated command prompt or application, otherwise you would be inheriting full privileges silently)
    I'm going to replicate your same test as soon as I have a couple of minutes to try that out.

    Another question: how do you know that Virtualization is being used?
    Are you using Windows' Task manager, showing more columns?
    Are you looking to your VirtualStore folders?
    My favourite way is through Sysinternals' Process Explorer  (BTW: their tools are really great, and
    now sysinternals are inside microsoft's site)

    Maybe there could be another question: when you run an application that was previously run virtualized (ie. that triggered the file-on-write copy mechanism resulting in some files being written "away", in your VirtualStore), does it run virtualized or not?
    Try cleaning out all of the app's files that were places in the virtualstore and then run it again.
    HTH, Luke
    Thursday, March 15, 2007 11:42 PM
  • I've tried executing and application (with no manifest) in order to get some virtualized file around. I then embedded a manifest specifying runLevel="asInvoker" and run it again.
    I can confirm that without manifest it "sees" the virtualized files and with the manifest in place it sees the "real" files, even if the virtualized ones were still there..
    I've tried both .v2 and .v3 namespaces for the trustInfo tag, without noticing differences:
    without the manifest, app gets virtualized; with it, it doesn't...
    Have you tried making a "prototype", a simple unuseful executable that does nothing special, to see if manifests are working as you expect them to work?
    A simple test case often relieves hours of head-ache...

    Hope to hear from you soon
    Luke
    Tuesday, March 20, 2007 1:55 PM
  • hi

    in test case one it says "Any application that is required to run as administrator or requires an elevated privilege to run properly must receive a waiver form Microsoft in order to pass this test case."

    what is a waiver exactly and how can i get it?

    Monday, April 02, 2007 7:57 AM
  • Try looking at this page: InnovateOnVista
    the waiver document should be this one

    HTH
    Luke
    Monday, April 02, 2007 8:56 AM
  • A "waiver" is a request you send to Microsoft for a component that does not pass some specific test cases (among those that can accept waivers) and tell them what does not work and why.
    You'll probably ask a waiver for some Microsoft redistributable files that are not signed, for instance, since there is a test case (n.5) that requires all executable files to be signed: so you'll have to ask for a waiver for those which are not signed.

    You can find a "sample" waiver document from the links I've posted above. It has to be filled in and sent to 'swlogo@microsoft.com' for approval. When approved, they'll send you back with a reference number you'll have to use in the following certification steps.

    Hi,
    Luke
    Friday, April 20, 2007 4:34 PM
  • I think it's better to obtain an Authenticode Digital ID from Verisign than to fill a waiver request.
    Wednesday, April 25, 2007 12:31 PM
  • Hi Dennis,
    I agree with you, but you'll have to consider that in some scenarios using waivers is necessary:
    1. if the code is yours, you should digitally sign it and that's ok
    2. if the code is not yours, you might not be allowed to sign it (because of copyright issues or such..): so you should either ask their authors to sign it or, at least, have their written permission so you can do it by yourself
    3. we had a DLL we were using in a product, but it wasn't supported anymore (the company had been incorporated into another one, so no one was responding anymore..): in that case we could not do anything but asking a waiver
    4. we also had some DLLs from Microsoft, which were not signed: we did not sign them, instead we asked for a waiver
    We had no troubles in getting them approved. Anyway you should be aware that you will be able to ask for waivers only for some specific test cases and under some specific conditions (simply read the sample waiver document they provide)

    HTH
    Luke
    Wednesday, April 25, 2007 1:55 PM
  • Luke - you have made reference to mt.exe (6.0.4071.0). I have what appears to be two versions of mt.exe on my Studio 2005 SP1 machine (which I also hear is not uncommon), both with a version of 5.2.3790.2075: one dated 10/19/2006 14:52 and another dated 12/02/2006 08:17. Martin Richter's bug post claimed that the 10/19/2006 one (which both he and I got from the Vista SDK) is the better one to use to avoid the crash in XP with the duplicate namespace problem described above. I used the suggestions of pwoods above and embedded his "improved" trustInfo section into my manifest using Additional Manifest Files in app properties:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urnTongue Tiedchemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <trustInfo xmlns="urnTongue Tiedchemas-microsoft-com:asm.v2">
    <security>
    <requestedPrivileges>
    <requestedExecutionLevel level="asInvoker" uiAccess="true">
    </requestedExecutionLevel>
    </requestedPrivileges>
    </security>
    </trustInfo>
    </assembly>

    but I get the warning

    manifest authoring warning 81010002: Unrecognized Element "requestedPrivileges" in namespace "urnTongue Tiedchemas-microsoft-com:asm.v2".

    Would mt.exe v6.0 fix this? If so, where can I get it? It does not appear to be in the Vista SDK.


    Friday, May 18, 2007 8:41 PM
  • Hi Bill,
    I didn't remember that.. Anyway I've two versions of mt.exe on my computer, 5.2.3790.2075 and 6.0.4071.0. The latter is the one I used in my tests..

    The older ones are under VS2005:
    C:\program files\Microsoft Visual Studio 8\SDK\v2.0\Bin
    C:\program files\Microsoft Visual Studio 8\VC\bin
    and under Vista SDK:
    C:\program files\Microsoft SDKs\Windows\v6.0\Bin

    The newer one is under VS2005 too:
    C:\program files\Microsoft Visual Studio 8\Common7\Tools\Bin

    I don't know if that got installed with VS2005, VS2005 SP1, VS2005 SP1 Update or what else... Probably it has been placed there by some other MS product or SDK, but as of now I still couldn't find its source package... its container folder was created on a day in which I installed a lot of things, so it's not easy to guess which one is the right one Sad
    I'll tell you if I find it.
    Tuesday, May 22, 2007 2:05 PM
  • I have the same directories, but they all have either 10/19/2006 14:52 or 12/02/2006 08:17, none of them v6.0. And I have Studio 2005 SP1 (but not SP1 update for Vista). I'll try installing the SP1 Update and see if that gets it.

    But v6.0 works correctly for you, right?
    Tuesday, May 22, 2007 2:36 PM
  • And even better: I installed Studio 2005 with SP1 in a clean virtual machine and lo and behold the v6.0.4071.0 version of mt.exe appeared in C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin with a date of April 04, 2005, 19:43:18 !!!

    So v6.0.x is "older" than v5.x. Hmmm.
    Tuesday, May 22, 2007 5:34 PM
  • Hello,

     

    I'm trying to modify the manifest for vb application but I'm stuck on the manifest tool step.

    Open your project in VS
    Under project , Select properties:
    Go to manifest tool->Input and Output
    Go to manifest tool->Input and Output

    Is there some other way to do this?

     

    Thanks!

    Daniel

    Monday, June 04, 2007 9:49 PM
  • I know what the problem is.

     

    The runas will cause a blue screen. This is because XP/2003, runas has a completely different

    meaning. Runas causes process elevation in Vista, not XP and 2003. In XP and 2003, runas

    means switch as a valid use (eg Everybody\kgatton). However, in Vista runas either will change

    the invoke, or elevate a process is called blank from a shell command. That is why XP and 2003 crash.

     

     

    Only use runas=<elevation> in vista. DO NOT use this manifested file in 2003 or XP.

     

    Tuesday, October 30, 2007 11:11 PM
  • Hi all,

     

    There's a way to include a manifest resource in your app without using MT at all.  This avoids the danger of VS generating an invalid one which blue-screens XP, and can be entirely automated within VS 2005.

     

    First, create a text file, let's call it my_manifest.txt, containing your entire manifest resource; mine looks like this:

     

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

     

    <assembly xmlns="urnTongue Tiedchemas-microsoft-com:asm.v1" manifestVersion="1.0">

    <assemblyIdentity

    version="1.0.0.0"

    processorArchitecture="X86"

    name="AlpineSoft.Test"

    type="win32"

    />

    <description>This is just a test program.</description>

     

    <trustInfo xmlns="urnTongue Tiedchemas-microsoft-com:asm.v3">

    <security>

    <requestedPrivileges>

    <requestedExecutionLevel

    level="requireAdministrator"

    uiAccess="false"

    />

    </requestedPrivileges>

    </security>

    </trustInfo>

    </assembly>

     

    Then add the following line to the 'Compile-time directives' box in your Resource Includes:

     

    CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "my_manifest.txt"

     

    Finally, in your project's properties, tell the manifest tool not to embed a manifest of it's own.

     

    At least, that's what I do for my C++ projects.  I don't know if / how one could do this for a managed assembly.

     

    Hope this helps - Paul Sanders

    http://www.alpinesoft.co.uk

    Wednesday, November 07, 2007 1:30 PM
  • Hi, in my vb.net solutions, there are 3 projects, let say A, B and C and C is the deployment project. I use post build in project B to embeb a manifest and it success. The problem is when I deploy the entire solution n installled the application. B is not embeded with manifest. I did recheck the release folder of B, B.exe is embeded with manifest but B.exe in installed location is not embeded.

    Wednesday, March 26, 2008 3:40 AM
  • I'm having a similar problem... I have 3 projects within my solution that have a manifest attached via post-build event using MT.EXE. Now they ALL work after building them if I just copy them to a Vista machine and they will ask for the elevate permissions, however... when I build my installer, only ONE of them somehow loses its manifest (or its replaced with something else) as it will not request elevation when ran. The other two still have their properties correct and work right.

    Does anyone have any idea why one would be losing its settings while the other two don't?
    Friday, March 13, 2009 12:27 PM