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
Manifest files for Vista
Matthew Lebo28574
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
errodr
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
GlitchEnzo
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
Farhan H Soomro
SP1 beta does not resolve this problem with mt.exe
so, the best workaround i know is just to delete $(VCInstallDir)bin\mt.exe :)
Tom_Liu
El Gaseron
<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
Docpro777
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.
SaintAnger
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
Adrian Heath
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.
Alistair Leslie-Hughes
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
Arunkjose
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.
LouArnold
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).
EsteemDE
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.
Pra_na_b
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:
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:
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.