You do AssignProcessToJobObject and it fails with "access denied" but only when you are running in the debugger. Why is this?
This one puzzled me for for about 30 minutes.
First off, you probably need a UAC manifest embedded in your app (as suggested here). Something like this:
<?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="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Secondly (and this is the bit I got stuck on), when you are running your app under the debugger, it creates your process in a job object. Which your child process needs to be able to breakaway from before you can assign it to your job. So (duh), you need to specify CREATE_BREAKAWAY_FROM_JOB in the flags for CreateProcess).
If you weren't running under the debugger, or your parent process were in the job, this wouldn't have happened.
This seems to bite me quite often, and while good, 1800INFORMATION's post doesn't seem to include a number of reasons and fixes that seem helpful, so it seem worthwhile to post a summary of why I've seen this happen.
When trying to solve this for yourself, note than this problem
can occur for different reasons when running from CMD.EXE, Explorer,
and Visual Studio. Trying to run the failing executable from the
respective places can help identify the cause of the problem. You
app may just work find from CMD.EXE in spite of failing from V.S.
and Explorer.exe
In my case, under Win7, I seemed to need to un-comment the "supportedOS"
element indicating Win7 compatibility from the app.manifest
file. This seems to fix the problem when running from Explorer. To
add a manifest, right click on the project, hit Add, and find
'Application Manifest File'.
To get Visual Studio 2010 working, I seemed to need to stop it from using the Program Compatibility Assistant, Tom Minka shares two ways to do this here: https://stackoverflow.com/a/4232259/86375, note, I had to restart VS2010 to take his suggested changes.
Related
I'm experiencing an odd and continously reproducable issue with Visual Studio 2013 Ultimate I'm hoping someone can help me glean insight into.
I recently deployed a C++ application, I am developing, to one of my older laptops. When executed, nothing happens. Almost literally. It simply ends execution and returns immediately. It's supposed to do quite a bit more. I thought I'd address this problem using Visual Studios automatic deployment and debugging abilities.
I like to take things in very small increments when trying new things, and the guides I've found on how to remotely debug and deploy have left me still feeling a bit confused/unsure.
So - I took the smallest step I could, by just selecting 'Remote Windows Debugger' and clicking that:
This expectedly pops up an error message:
Following the advice, I am unexpectedly greeted with this in the property pages:
I have absolutely no idea why this happens.
I know the cause, in a sense. By fiddling around I found that the debugging changes are contained within the Application.vcxproj.user file. Prior to running/configuring any remote debugging it looks as follows:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
after just attempting to run remote debugging, it looks as follows:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<DebuggerFlavor>WindowsRemoteDebugger</DebuggerFlavor>
</PropertyGroup>
</Project>
Reverting to the previous file state, the properties show up just like they're supposed to.
But why (seemingly) any change causes Visual Studio 2013 Ultimate to go a bit sideways is beyond me. I first stumbled on the issue by following one of the aforementioned guides where I started out by just updating the Deployment Directory in the properties and then clicking Apply. This caused Vs2013 to crash and lead to the same blank property page.
I should note that this issue occurs with a freshly created console application.
Anyone ever tried anything similar or got any suggestions as to how to perhaps cure this problem?
I need to create an application which needs to create files/folders in "C:\Program Files","Users[username]" and Sys32. Also the application needs to make some registry entry.
This application needs to work on Vista and higher. Also, on Windows Server 2003 and higher.
The above Operating Systems have the concept of User Account Control (UAC), where to access Program Files and writing in registry requires admin privileges.
I looked into many forums and found that using Microsoft SDK we can check whether the current user have admin privileges or not . But the function "CheckTokenMembership" fails for Vista and higher version of OS.
I also found a solution where manifest file can be used to tell OS in advance that the current application requires admin privileges. This is done using "requestedExecutionLevel" tag.
I am using Visual Studio 2005 to create the application. When we create an application in Visual Studio a default manifest file is created. Can I change this manifest file to include "requestedExecutionLevel" tag, so that my application always runs with admin privileges?
Is there any other method through which my application runs with admin privileges without asking user (admin or standard) to run my application as "run as admin"??
Thanks!
You should find an option for this in project properties Linker -> Manifest File -> UAC Execution Level. Set this to requireAdminstrator.
This will cause the default generated manifest to include the requestedExecutionlevel that you need, so that your users will be prompted automatically to elevate their privileges if they are not already elevated.
Acknowledgements and Introduction
This question helped me and I will help back with the knowledge I gained. Thanks to:
Lipika(The person whom asked the question) revealing that admin access was the reason why access to system directories were redirected to virtual directories. It was later clear that lack of admin access cause writing to certain registry keys to fail.
snowcrash09 for revealing the Visual Studio option for enabling require admin access. With further research on MSDN, I got the manifest to not embed into the executable under Properties>Manifest Tool; thus allowing me to read it.
Nayana's link to polynomial's answer is also good. Here I will borrow part of his answer in my demonstration.
Answer
As Lipika have stated, you require admin access, else Windows Vista and up will redirect you to a virtual directory. Which is great. Logically then your app should request admin access. You can let the user do it manually. If not, Windows provides many ways to do this programatically. The easiest way is to declare it in your app's manifest. Here I will dedicate instructions to individuals not using Visual Studio. If you are using Visual Studio, it is as easy as Properties>Linker>Manifest File>UAC Execution Level.
If you are using CodeBlocks for example; create a file called app_resources.rc. With CodeBlocks its very import that this file has the .rc extension, so CodeBlocks knows to compile it with windows resource tool. Copy the following code into this file, and add it to your project.
#include <windows.h>
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "adminAccess.manifest"
Create a manifest file called adminAccess.manifest. copy the following code to the file. Do not need to add this file to your project as it is reference from your rc file.
<?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="MyApplication"
type="win32"/>
<description>Description of your 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>
Now you can compile your app and it will automatically prompt for admin credentials when run. It will return failure if admin access was not granted. On Windows Xp, you won't be prompted for any authentication.
Note that from here you can edit the manifest to add features such as visual styles for Windows widgets and DPI awareness.
If you are not using CodeBlocks. For example you are compiling from the command line. You pretty much have to compile the rc file with the Windows Resource Tool. In MinGw build tools, this is called windres.exe. It will compile a .res file. You then link this resulting file, with all the other files you will be linking at the linker stage.
Note that the rc file is a windows resource file and carries all the resources your app uses such as BITMAPs, ICONs, STRINGs, dialog template. Which will all be stored in the final executable. Which you can then load from the executable using Windows specific functions. This is pretty similar to what Android does.
My fairly normal MFC-based Windows application works fine on Windows 7. But when I run it in Windows 8, no UI appears. At first I thought it somehow wasn't launching properly, but eventually realized that if I bring up the Task Manager, it shows that my application is running but it's listed under the "Background processes" section.
What heuristics is Windows 8 running on a process to decide it is a "background process"? Or is there something I can do--perhaps in the application manifest--to explicitly label my application as a foreground process?
I have tried running in Win7 and XP compatibility modes, to no avail. I have tried several Win8 machines, all give the same result.
For what it's worth, this app is compiled with Visual Studio 2003 and I do not have the option of using a newer compiler.
I have googled things like "win8 background process" but all I'm getting are people who want to create a background process. Some of the answers suggest that a background process has to be registered using the application manifest, but I double-checked my manifest and it definitely has nothing in it about being a background process.
Here's my manifest, in case you can see something off in it:
<?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="MyProductName"
type="win32"
/>
<description>My Product Description</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<asmv3:trustInfo xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:security>
<asmv3:requestedPrivileges>
<asmv3:requestedExecutionLevel level="asInvoker" uiAccess="false" />
</asmv3:requestedPrivileges>
</asmv3:security>
</asmv3:trustInfo>
</assembly>
I will be opening a support incident with Microsoft to get their help if I can't find an answer here. If it gets to that point, I'll certainly update this question with what I find.
I'm developing Windows 8 applications but not much knowledge of MFC development. so based on my knowledge MFC development is more similer to Silverlight development but Windows 8 development is more different than MFC development platform.
by the way, "Classification of Background Process in Win 8":
The Process of application which is in suspend mode, that means the application is running but not showing any UI due to Desktop mode.
to clarify my self on this point I checked once more by creating a tread in win 8 by XAML & C#, and made that thread as in suspend mode, only at that time that process showing as background process in task manager.
moreover that "Specifically for Windows 8 only" :
The process of any app shows as background process when Provided Resources to the app will decreases or will d-allocate those resources but still application is loaded and running...
This feature of Windows 8 is known as "Auto Resource allocation"...
sorry if you not find your answer here but i think this can help you to know "Which process is classify as Background Process in Win 8"
This is pure speculation on my part, as I can't find any documentation on this, but I suspect that something in MFC is failing, and the lack of a working UI is why Task Manager is classifying your app as a Background Process, since the user is not able to interact with it.
I posted this on programmers first, but was told it belongs here. Funny, I didn't think so.
I have VS10 installed on a Windows Server 2008 R2 box, along with several other versions of VS dating back years. This is our production build machine.
When I load or create any C++ project and do a Rebuild or Clean, the IDE crashes. In the crash details, I see this:
I have seen other reports what seems to be the exact same error on the web (example). Other than the advice to open a ticket, I've seen no solution.
Has anyone else encountered and fixed this problem? I've opened a ticket with MS, but I'm covering my bases posting here as well.
EDIT:
I ran a logfile as suggested in comments. These are the only entries that occured after I loaded up VS, so this includes the build & the crash:
<entry>
<record>229</record>
<time>2010/12/01 19:35:39.804</time>
<type>Information</type>
<source>VisualStudio</source>
<description>Entering function CVsPackageInfo::HrInstantiatePackage</description>
<guid>{68939055-38E0-4D17-92CB-8909710D8178}</guid>
</entry>
<entry>
<record>230</record>
<time>2010/12/01 19:35:39.836</time>
<type>Information</type>
<source>VisualStudio</source>
<description>Begin package load [Windows Forms Designer Hosting Package]</description>
<guid>{68939055-38E0-4D17-92CB-8909710D8178}</guid>
</entry>
<entry>
<record>231</record>
<time>2010/12/01 19:35:39.882</time>
<type>Information</type>
<source>VisualStudio</source>
<description>End package load [Windows Forms Designer Hosting Package]</description>
<guid>{68939055-38E0-4D17-92CB-8909710D8178}</guid>
</entry>
How about contacting MS support directly? If this is blocking your work, you can push them to have it fixed (don't know about costs though, will probably depend on the product and specificities of your license...).
Alternatively, you can build your solution in the commandline: open a VS 2010 command prompt (shortcut is located somewhere in the start menu):
msbuild yoursolution.sln /p:Configuration=Debug
That shouldn't use devenv.exe (which is the thing crashing here) and invoke the tools directly.
The P8 bucket has a strange value, at least when compared to my machine. Check this post for a way to reverse-engineer the crashing method. The crashing assembly is stored in the C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.Shell.10.0\v4.0_10.0.0.0__b03f5f7f11d50a3a directory on my machine.
The P7 bucket (note that yours doesn't match the linked one) points to ServiceProvider.GetService(). The P8 bucket gives an IL offset of 0x4b but I see the method end at 0x41. However, I haven't yet figured out how accurate that can really be when the JIT compiled code gets optimized.
If this is anywhere accurate then you don't got much for a lead. A GetService() method is hopelessly generic. Although it certainly looks like it came up with a bad one that didn't survive a cast. It is the kind of stuff that addins can mess up.
Btw, this doesn't actually affect the build output, MSBuild.exe runs as a separate process.
For anyone still having this problem, the answer that fixed mine was that I had tried to completely wipe Internet Explorer from my computer- leading to the DLL call failure that crashed devenv.
Here is their official solution page:
http://support.microsoft.com/kb/983279
My question to Microsoft is... Why would a dependency on internet explorer to compile applications even make sense under any circumstances?
I've created a DLL project in VS 2005 for native Win32/unmanaged C++, call it myProj.dll. It depends on a 3rd-party commercial DLL that in turn depends on msvcr90.dll (I assume it was built from a VS 2008 project). I'll call it thirdParty.dll.
My DLL project builds just fine in VS2005. I've built a test app (again, VS 2005 Win32 C++) that links to myProj.lib. (As an aside, judging by the small size of the .lib, and by the fact that, at run-time, the app must locate myProj.dll, I'm guessing that the .lib is just a wrapper for a call to loadLibrary() that loads the actual DLL; is that close?)
My problem is that, at run-time, the test app cannot locate msvcr90.dll (nor msvcp90.dll), the dependency on which stems from the thirdParty.dll.
I've installed Microsoft's redist package, and so have all the std (9.0) C++ libraries in c:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_... . What's more, if I point the dependency walker at thirdParty.dll, it happily resolves the references to that location.
But, if I point depends.exe at my test app (.exe) or myProj.dll, msvcr90.dll and msvcp90.dll are not found.
I'm guessing there's something I need to configure in VS2005 so that the .exe or myProj.dll are aware of the location of the 9.0 versions of the std C++ libraries (presumably where the redist package installed them in C:\WINDOWS\WinSxS), but I can't seem to figure out what it is. Am I on the right track?
I note that, if I simply copy the msvc*90.dll files to my app directory, then the dependency is resolved, but I get the run-time error about improper loading of std c++ DLLs, etc.
Thanks immensely in advance.
This looks like a "Side-by-Side Assemblies" issue to me.
From what I can tell, Microsoft in an attempt to stop the DLL Hell problems of past years has introduced a concept of "Side-by-Side Assemblies".
In a nut shell it means that your application needs to tell Windows which version of the CRT it was designed to work with. When the application is installed Windows will make sure you application gets its own private copy of these DLL files.
To make it all work you need to embed the application's DLL dependencies into the applications Manifest file and attaching it to the project using the Manifest Tool, Input and Output section of the application project settings.
As an example here is the manifest I use for the Zeus for Windows IDE:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
name="Xidicone.Windows.Zeus for Windows"
version="3.9.6.69"
processorArchitecture="X86"
type="win32" />
<description>Zeus for Windows</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.VC80.CRT"
version="8.0.50608.0"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*" />
</dependentAssembly>
</dependency>
</assembly>
Finally, if you plan to make an installer you will need to add the same versions of these DLL files to the application installer or alternatively have your installer run the Microsoft CRT redistributable installer.
FWIW I only found out about this when a user reported that Zeus no longer ran on Windows XP because of a missing MSVCRT runtime DLL file, yet Zeus had been working fine for over 10 years without ever once having to ship with a MSVCRT runtime DLL file.
Did you install the SP1 version of the msvc 2008 redist?
It is not a problem if depends.exe cannot find the msvcr90.dll, if you use the microsoft installer it is automatically installed in the correct location, and will be found if your application is run. It does not help if you copy the dll's to your application directory if you do not create a manifest.
But can you tell the exact error message you get?
You can also take a look here and here regarding the manifest.
I would ask the third party dll people about this.
I have the same problem some days ago. myProj.dll depends on a thirdParty.dll, which uses msvcr90. If I build a test.exe using directly myProj.dll, it is ok. But if I use loadLibrary(myProj.dll) in test.exe, the call will just fail. The same would happen if I try loadLibrary(myProj.dll) in a Java program.
After some investigation and research on Internet, the following steps have resolved my problem.
Make sure that NO msvcr90 is on the PATH.
You can use process explorer (procexp.exe of SystemInternals) to find out all msvcr90 currently loaded in your environment. As a matter of fact, starting from VC 2005, C runtime libraries should only be installed in the Global Assembly Cache (\winsxs....), not even under windows, or windows\system32.
embed the dll manifest in myProj.dll.
After cl.exe and link.exe producing myProj.dll, a corresponding manifest is also produced.
Then use mt.exe -inputresource myProj.dll.manifest -out myProj.dll;2
The above solves my problem, hope that it could be of any help to you.
BTW, I am using VC 2008 under Windows 2008 R