I have a 32-bit application I'm working on that targets .NET 3.5; VS2010 is my development tool. My app requires elevated privileges for a variety of things, so I have an application manifest for it that has the following line in it:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Because it's the right thing to do, I also have the lines in the manifest that indicate the application is compatible with Windows 7 and Windows Vista:
<!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
The app runs great on Windows 7 and Windows Vista. It immediately pops up the UAC prompt, it does not get affected by registry virtualization, etc. The manifest is clearly working there.
However, on 2008 R2 none of these things are true. UAC prompt does not appear. Registry virtualization happens (my primary problem). It's like it's completely ignoring my application manifest. I have no idea where to look or what to check. I have run the exact same bits on 7, Vista, and 2008 R2 and get exactly the same results every time. My 2008 R2 install is completely vanilla, as it's just a freshly-installed VM for testing.
Also, I'm fairly sure that Server 2008 is acting just like 2008 R2, basically ignoring the manifest. Any help would be greatly appreciated!
I have figured out the strange answer to my own question, though it comes in two parts:
For some reason, I'm not getting a UAC prompt in either 2008 or 2008 R2, but in both cases the app is getting properly elevated and application virtualization is disabled correctly.
My app, being 32-bit, was writing into the Wow6432Node registry key, hence I thought virtualization was happening because my changes weren't appearing. If I had tested on 2008 x86, which I had not, I would have found that the changes were appearing there but not in the x64 OSs.
Server 2008 R2 has UAC turned off by default. If it's turned off, then users from Administrators group have full admin rights and non-admin users do not have them and can't be elevated into an administrator account.
Related
Cannot change dcom permission on Windows x64 2012 R2 datacenter. The component is 32 bits. I start the config running "mmc comexp /32". I can change it, but Windows won't save the configuration. I check "customize" (the picture shows Windows in portuguese, so it's 'Personalizar') and save. When I come back to the security tab, it's again on "Default". I already went to regedit and gave all possible permissions on the component entry. Check image here: http://imgur.com/VVNVLMo
Another thing, I can't change the configuration of most components,
they are grayed out.
Any idea to fix this? Windows makes so unthinkable problems :z
We are migrating our applications from windows xp to windows 7. One of the application is window and mouse hook. same code is working fine in windows xp but it is not working in windows 7 target machine(windows 7 installed with our own software platform).
One important thing is its working fine in my personal laptop which is having windows 7 os
i dont know what is happening...
please help me to resolve this...
There are increased security features in Windows 7, and that's probably what you're running into. Try running your app as administrator on your target machine (right click, run as admin).
I haven't tried such a hook in Win7 myself, but I saw this happen from XP to a Vista box.
I have found the answer. actually our application does hook every process we create. i have created 32bit dll. target machine is 64 bit so every process is 64bit right. so it tried to load my hook dll(32bit) into 64bit processes. we cannot load 32bit dll into 64bit exe...... :)
I have an old VB6 application that depends on MSINET.OCX. I'd like to know if I can distribute this application without registering MSINET OCX component. My target OSes are XP, Vista and Windows 7. Do all of them have this component preinstalled?
See if this information from technet helps you. The short of it seems to be that it does not come preinstalled, it is installed when you install an application that uses it. You will need to include it in your installation.
It's not shipping with the OS. It is however delivered with Visual Basic. You must include it within your application setup. For details on Vista and Win7 support see: Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7
As per requirement we have written one custom GINA. I have observed one interesting behavior in Windows XP 32 Bit(SP2). Customized GINA internally calls windows default Windows GINA (msgina.dll) and shows one extra window as per our requirement.
I used to do remote desktop to XP machine from my machine. After replacing Windows GINA with customized GINA I tried to log off from the XP Machine (I am Using Remote Desktop Connection to log in), Log off completes successfully (After showing saving your settings, Closing network connections etc) and I will get log in screen which we get during log on, this is not expected compared to other flavors of Windows OD.
Where as in other operating systems such as Windows XP 64 Bit/ Windows 2003 32/64 Bit even after replacing the Windows Gina with custom GINA remote desktop session closes after log off from the machine. I have tried installing Novell GINA on Windows XP 32 Bit but I have not find any issue with that.
I have Tried upgrading XP SP2 to SP3, still I am facing the same issue.
Has anyone else faced such issues when working with Windows GINA?
I cannot say that I had the same issues. Are you passing most of the functions through to msgina or do you do a lot of custom processing (and replacing the original code)?
My custom GINA was a very shallow wrapper of existing functionality and worked perfectly fine on Windows 2000, XP and 2003.
However, as to the differences in behavior: XP x64 is based on the Windows 2003 Server code base. So this could well explain some of the similarities between those and differences to "vanilla" XP.
We have a Server/Client cybercafe management application which used to work fine on Windows XP and Vista but now fails to run on Windows 7.
The Client was supposed to get 'Locked' on Client PCs of the Cybercafe, meaning it replaced Windows Explorer by changing the registry key
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell"
to the path to the Client application's EXE file.
This worked just fine on Windows XP and now on Windows 7, neither Explorer.exe nor Client.exe are run and just a blank, blue screen is shown.
We thought it might have something to do with UAC so we disabled it, with no luck.
When we managed to start Explorer.exe on the Client PC through another computer, and used the Explorer window to open Client.exe, the Client started just fine.
(Note that running Explorer.exe didn't start Windows Shell and just opened an Explorer window, since the registry key was pointing to Client.exe and Shell doesn't start unless the registry key points to Explorer.exe)
Ideas, everyone? Any big difference between XP and 7 in this area?
Fixed it. Hope someone finds this useful:
A 32bit app running on 64bit Windows can't access certain areas of Windows Registry. The request to access that section is routed to some other key. That's why our application couldn't lock on Windows 7 (It was a 64bit Windows).
Changing Client.exe from x86 to "Any CPU" in Visual Studio fixed the problem.
However, it was still necessary to disable UAC to allow the Client to work.