Background:
I'm developing an windows service and using the registry to get the parameters (using the key Parameters below the service entry).
Delphi is installed as an AppWave app (long story I cannot tell here) and therefore when debugging it goes to an virtualized copy [1] instead of the real deal [2].
I detected that after going logging registry activity of the service using
Process Monitor. If I run the service outside Delphi, the application
access the real key normally.
Question: there's some way to circunvent Streaming Core and debug the app
accessing the real registry key?
Note to mods: since there's no AppWave tag, I could not include it - I tried.
Virtualized copy: HKEY_LOCAL_MACHINE\software\Embarcadero\StreamingCore\Profiles\fabricio\Applications\{<<GUID>>}\Virtualization\Keys\whklm\SYSTEM\CurrentControlSet\services\[service]\Parameters]
Real deal: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\[service]\Parameters
The whole point of AppWave to is sandbox and virtualize applications. So no, AFAIK your service cannot bypass AppWave's Registry virtualization while running inside of the sandbox.
I've never used AppWave myself, but assuming it allows network connections, you may have to resort to using the IDE's remote debugger. Run the service outside of the sandbox, and then have the IDE connect to the remote debugger, which can then debug the service process.
I didn't found an way. The remote debugger approach - suggested by Remy's answer - when used on the same machine ended affected by the StreamingCore service.
So the approach used is logging to do the debugging. For that, used CodeSite Express (which is very handy and included in Delphi) to do the logging.
Related
Like some cyber coffee applications that disables the user ability to use any other application but only the ones started inside that cyber admin application panel, I searched the Internet for some way of doing it in Delphi:
Remove the Windows Task bar;
Disable the Alt+Tab function;
Disable the Task Manager;
Be able to do/undo that changes in a configuration panel.
These needs are for keeping users from downloading viruses and making changes to Windows configuration or even play games, if it is the system administrator's preference. The own program would serve as a container for authorized applications to run inside then as if it were a MDI application. That is already working
Of course that the system manager will have the options to disable that or revert.
Is there a way to make those four configurations in run-time with Delphi XE3?
I'm not familiar with Delphi. I'm also not sure if it is possible during run-time. But you could do the following:
Write to the registry to prevent alt-tab see this.
Again write to the registry to disable Task Manager see this.
Sounds like you can disable the task bar too by the registry see this.
On your control panel have options and when they hit save, save and restart the computer.
This is provided that Delphi can write to the registry (I believe C# and C++ can). If not, you could create .reg files and execute those by calling cmd.exe with arguments. This I think will cause some pop-ups though.
Update: You may be able to load in the registry changes without a signing out by killing explorer.exe and then loading it again. This may only load parts of the updated registry though.
I'd suggest booting your hardware into Linux, and then run a Windows virtual machine that is as locked down as possible using the existing kiosk mode security settings in Windows. This VM then runs your MDI application when the VM boots. When the MDI application exists the VM reverts to a snapshot of the known good Windows configuration.
You strip down a Linux OS to include only the bare minimum components needed to host your Windows VM.
I'm assuming your MDI windows will only host applications your organization has written, not arbitrary Windows executables. Otherwise you are asking to re-write Windows itself, which will prove impossible.
I'm looking to determine if our application is running on a XenDesktop session rather than locally. Here is what I have found so far:
We currently have code to detect a Citrix XenApp session similar to the solution mentioned by Helge Klein in "API for Determining if App is Running on Citrix or Terminal Services".
Sadly that solution in a XenDesktop environment is returning back a WTSClientProtocolType of 0 which signifies a local console session.
In response to the same question Josh Weatherly mentioned checking the sessionname environment variable.
However a quick console check with echo %sessionname% on the XenDesktop environment returns back 'Console'.
From "Detect citrix “application mode”?" John Sibly suggested a solution for detecting a remote session (not Citrix in particular):
GetSystemMetrics(SM_REMOTESESSION) however returns 0 which also means that it is a local session.
Does anyone know of a way to detect that it is a XenDesktop session? So far as you can see all my attempts are returning that the session is a local console session.
I'm using XenDesktop Express 5.5, accessing the desktop using the Citrix Receiver Web Plug-In.
If you are using XenDesktop for VDI, then as far as the application is concerned, the application is executing locally. VDI, or virtual desktop infrastructure, consists of delivering the GUI from a full featured desktop operating system to a remote device. Typically, the desktop O/S executes in a virtual machine on a hypervisor in a data center, and the GUI is transmitted to the remote device using Citrix' ICA stack. For example, this happens in the pooled desktops scenario.
XenApp offers virtual desktops, which is a slightly different concept. Again, the desktop is delivered to a remote device using the ICA stack. However, the desktop is no longer running on a dedicated O/S. Rather, it is one of a number of user sessions on a single Windows Server. There may be any number of users logged on to that server. This places limits on the applications that can be run, which is why applications might want to know that they are on a multi-user O/S.
What you might try to do is determine whether the GUI is being delivered remotely using the ICA stack. A simple check would involve looking for the "ProticaService", which is responsible for implementing the ICA stack.
Alternatively, you may be trying to determine if your machine is running in a VM or native to a machine. Besides the pooled scenario described in the first paragraph, XenDesktop can deliver desktop running native. This overcomes limits on virtualision I/O devices such as graphics cards used by CAD applications. In this case, you need to rule out the presence of a VMM, or hypervisor.
I have updated my answer linked to in the question with a description of how to determine the remoting protocol type in XenDesktop sessions.
You need the (not really well documented) function WFGetActiveProtocol from Citrix' WFAPI SDK. Proceed as follows:
Download the SDK (link)
Install WFApiSDK64-65.msi
In your C++ project include wfapi.h and link to wfapi[64].lib
Use the undocumented function WFGetActiveProtocol
More detail and sample code here.
I need a background application to support my client application, which should always run on the client machine regardless of the main client application is running or not.
Windows Service was my first choice but problems I faced with Windows Service were: ease of control over windows service through main client application, release and installation of patches to the windows service and troubleshooting if windows service fails to run.
So, I started thinking for alternatives to the Windows Service and found that a Windows Forms application with NO visible forms can do it for me. This invisible app should start with system startup and keep running all the time, doing all the work that a Windows Service would do. But before I go deeper into the development, I want to explore the pros and cons of this approach.
Any suggestions/comments on this approach?
Your requirements are more suited for windows service. Main advantage with windows service is that it will start as soon as system comes up, irrespective of anybody is logged into system or not.
To sort out deployment issues, you build your business logic into separate assembly and call the necessary function withing windows service. This way you can deploy just the modified assembly.
Winform application with invisible form will not serve the purpose. HTH
That's not possible. User-mode applications must be started by a user, and will not continue to run when that user logs off. That's the purpose of the SessionEnding event: to allow you to shut down your app gracefully when the user logs off or the computer is shutting down. You can't just start something at system startup and keep it running all the time.
You need a Windows Service for that. But you should be aware that under Windows Vista and later, a service cannot interact directly with the user. They run in a separate process and are restricted from displaying their own UI. It's not clear from the question exactly what your needs are, but this is an important limitation of a Windows Service that is worth considering. A proper design really shouldn't require this, but there are apparently a lot of people to whom this new, more secure behavior is a real surprise. I explain this in more detail in related answers to this question and this other question.
While debugging the crash on customer's machine we noticed that our application runs under verifier.dll. e.g each thread stack starts with verifier.dll and every system function is intercepted with verifier.dll stub.
Common sense and running Google search for "verifier.dll" clearly indicates that this dll belongs to Application Verifier tool provided by Microsoft. However the stunning fact is that Application Verifier not even installed on customer's machine (appverif.exe not found on client's machine neither c:\Program Files\Application Verifier directory),.
What else could cause the program to run in such mode.
Application Verifier is a debugging feature of the operating system, so it is always there. It can be configured by modifying the registry even if you haven't got the Application Verifier tool installed on the system.
This article on MSDN gives details of the registry settings that control the debugging features of the operating system. It might be that someone or something has enabled application verifier on the system that you are seeing the exception on. If it isn't specifically enabled for your process it might have been enabled system wide.
Sounds like a virus scanner type thingy. However I suggest you use process explorer to look at the dll and where it's loaded from and and other such info.
Does anyone have a good guide to capabilities of Windows Services under XP? In particular, I am trying to find out what happens when a program being run as a service tries to open windows, but hasn't been given permission to interact with the desktop.
Basically, I have a program that is/was a GUI application, that should be able to run as a service for long term background processing. Rewriting the program to not display the GUI elements when doing background processing is a major effort, so I'd like to see if there is just a way to ignore the UI elements. It is sort of working now, as long as too many windows aren't opened. I'm trying to figure out what limits I might be running into. Ideally, there would be an MSDN page that discusses this, but I've had no luck finding one yet.
Generally, services should be designed to not have any visible UI. The entire point of a service is to run in the background, without UI, unattended. (Think SQL Server, IIS, etc.)
In most scenarios, a separate application controls the service's operation, should a GUI be needed. (Continuing the samples I just mentioned, SQL Server Management Studio, IIS Manager, etc.) These separate applications configure and manipulate the service (and occasionally, if needed, bounce said service).
If your service requires occasional UI, and said UI can't be isolated to a control app, then you probably should reconsider the fact that you're using a service to begin with. Perhaps a UI application which resides in the system notification area is the right pattern to use? (E.G., Windows Live Communicator.)
A service in Microsoft Windows is a program that runs whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as directory replication, process monitoring, or services to other machines on a network, such as support for the Internet HTTP protocol
Usually it is implemented as a console application that runs in the background and performs tasks that don't require user interaction.
The installed services can be configured through the Services applet, available from
Control Panel --> Administrative Tools in Windows 2000/XP.
Services can be configured to start automatically when operating system starts, so you dont have to start each of them manually after a system reboot.
Creating a Simple Service - MSDN Article
Writing Windows Services Made easy - Code Project Article
Five Steps to Writing Windows Services in C - DevX Article
If you should be thinking of eventually migrating to a newer OS such as Vista or Server 2008, you will find that you cannot give a service permission to interact with the desktop at all. Therefore, from the point of view of forwards compatibility, you should design your service to not require it.
A service in Windows XP can interact with the Desktop if its "Allow Service to Interact with Desktop" property (MMC -> service properties -> Log On tab) is checked. It is also possible to do so by doing the following:
hWinstation = OpenWindowStation("winsta0", FALSE, MAXIMUM_ALLOWED);
SetProcessWindowStation(hWinstation);
hDesktop = OpenDesktop("default", 0, FALSE, MAXIMUM_ALLOWED);
SetThreadDesktop(hDesk);
But be aware that presenting UI from a service process in Windows XP will almost always lead to a security problem (see Shatter attack). You should try to break out the UI part of your application from the service.
Usually the service won't have permission to write to the window station and desktop, so it will fail; even running applications that load user32.dll can fail simply because user32 has initialization code that wants to talk to the window station and can't get access to it unless the service is running as an administrator.