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.
Related
I have a test script created using TestComplete 10.0. The test script to uninstall then install a software and update config file. It hosted in a Windows 2008 R2 Virtual Box and I have tested using TestExecute and it runs successfully.
I have scheduled the run via Task Scheduler and I have created a bat file to run it. Task starts successfully but fails. I have searched in Google and found TestComplete fails when remote desktop session is disconnected for the user set to execute the task.
I have tried adding the tscon /dest:console but did not successfull.
Is there any other way to login to Windows Server 2008 R2 Virtual Box?
This behavior is documented and the TestComplete Help file contains a number of possible solutions for it. You can find this information in the Running Tests on Locked Computers help topic of the tool.
I'm currently reading the MSDN description of some Windows APIs, such as WTSEnumerateSessions for instance, and it has words, such as
... is used ... on a Terminal Server
and
... requires running Terminal Services
But there seems to be no explanation of what all that "terminal" stuff is and how can I make sure that it is actually running.
Can I be sure that every Windows XP SP3, Vista and Windows 7 machine has those terminal services running?
Terminal Services is the component of Windows that allows remote desktop sessions. Generally, you have a Windows Server that is running the Terminal Services role. Clients, whether it be a windows 7 box, or a thin client, connect to the terminal server using the RDP protocol.
WTSEnumerateSessions is meant to be run on such a server and returns a enumerated list of client sessions.
Windows XP, Vista, and 7 all have the ability to host remote desktop sessions, however it is not as powerful as the actual Terminal Services (now called Remote Desktop Services in Windows Server 2008 R2) role.
I have attached the process for my windows service which is running/started on my machine. In vs.net 2010 I have a few breakbpoints set in my service, but each of them says?:
'break point will not currently be hit'
what is the easiest way to get the debugging for windows services happening?
This is the correct way to debug the windows service but you should be sure that the files of the windows service are updated. I mean that whenever you build the windows service project you should stop the service, replace the windows service exe and the related dlls and then restart the windows service.
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.
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.