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.
Related
I have a Windows Service that runs an exe file and it is working fine under Win7 and Win8 Environments. But when I try the program in a Windows Server 2008 or Windows Server 2012 Environment, the service works but the exe file is not run. So I am wondering if there is a regedit key that blocks running of exe files when they are run from Session 0 or something similar.
I have noticed that Windows 2012 by default blocks running interactive programs. But I have already allowed it by setting the following value to zero.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows
NoInteractiveServices
When you install a Windows Service in Windows Server enviorment, you need to check Allow service to interact with desktop property in the service properties -> Log On.
When this property is enabled, try to restart Interactive Services Detection service.
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 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.
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.
Is it possible to install the x86 Remote Debugger as a Service on a 64bit machine? I need to attach a debugger to managed code in a Session 0 process. The process runs 32bit but the debugger service that gets installed is 64bit and wont attach to the 32bit process.
I tried creating the Service using the SC command, and was able to get the service to start, and verified that it was running in Task manager processes. However, when I tried to connect to it with visual studio, it said that the remote debugger monitor wasn't enabled. When I stopped the x86 service, and started the x64 service and it was able to find the monitor, but still got an error.
Here is the error when I try to use the remote debugger:
Unable to attach to the process. The 64-bit version of the Visual Studio Remote Debugging Monitor (MSVSMON.EXE) cannot debug 32-bit processes or 32-bit dumps. Please use the 32-bit version instead.
Here is the error when I try to attach locally:
Attaching to a process in a different terminal server session is not supported on this computer. Try remote debugging to the machine and running the Microsoft Visual Studio Remote Debugging Monitor in the process's session.
If I try to run the 32bit remote debugger as an application, it wont work attach b/c the Remote Debugger is running in my session and not in session 0.
This works on my machine(TM) after installing rdbgsetup_x64.exe and going through the configuration wizard:
sc stop msvsmon90
sc config msvsmon90 binPath= "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe /service msvsmon90"
sc start msvsmon90
We had the same problem when trying to remote debug a website that is running as 32 bit inside 64 bit IIS.
You can also do this:
Stop the default debugging service
(which will be x64 as the installer
will have been clever and configured
that one to run).
Navigate to the Remote Debugger start
menu folder and run the x86 debugging
service. Ignore the warning about
32bit/64bit.
Open the Tools->Options window of the
remote debugger app window and make
note of the value in the 'Server
Name' text box.
Now you can attach your visual studio
to it by copying the 'Server Name'
value into the 'Qualifier' text/combo
box on the Attach To Process dialog
of Visual Studio.
On a related note, there is also a low-level bug with Kerberos authentication if you are attaching from Windows 2008/7/Vista to a 2003 machine, reported to MS (and then closed as 'external') via Connect here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=508455
I haven't tried this, but here's a suggestion anyway:
Try installing the x86 remote debugger service manually.
sc create "Remote Debugger" binpath= "C:\use\short\filename\in\the\path\x86\msvsmon.exe /service msvsmon90"
Two notes:
You'll need to use short filenames
in the path to msvsmon.exe to
prevent having to quote the path
(since the whole command needs to be
quoted)
there must be a space after the
"binpath=" (and no space before the
'=' character). Whoever wrote the
command line parser for the sc
command should be cursed.
Then you can use the services.msc control panel applet to get it running with the right credentials.
You'll probably have to stop or maybe even delete the existing x64 remote debugger service.
I can confirm that what you want to do will indeed work. I often connect my 32 bit xp worstation to a x64 win2003 server with VS2008 remote debugger.
1) Install the x64 version. This also installs the x86 debugger but does not create a shortcut.
2) You can find the executable for x86 process debugging here... C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe
3) If you want to, pin it to the task bar.
Worked for me without installing additional software. I just copied the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger folder on the VM and started the msvsmon.exe from the x86 folder. Both my guest and host are x64.
Sometimes this error occurred, I just close visual studio and open it again, everything is OK!
Very strange behavior from vs
I ran into this issue today (64 bit OS and VS 2019). I changed Configuration to use x64 for the project, IISExpress to use 64 bit and Platform target to be x64. It still used the 32 bit debugger and complained. Finally, when I enabled Script Debugging it started using the 64 bit debugger. So I would say the combination of all did the trick.