Using C++/Win32 API I create myself an event trace session. My application must supported NT5 thus I can't newer the newer APIs.
I am using the circular mode flags and real time flags.
I have everything working apart from one snag, when I reboot the machine the ETW session isn't persisted, my service starts up and recreates the ETW session (as the reboot has wiped it) which then causes the log file to be overwritten.
According to MSDN I must use the "global" logger on NT5 of which there can only be one, or an "AutoLogger" on NT6 of which there can be many. However MSDN says:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363687(v=vs.85).aspx
The AutoLogger sessions increase the system boot time and should be
used sparingly. Services that want to capture information during the
boot process should consider adding controller logic to itself instead
of using the AutoLogger session.
Sounds like overkill for what I'm trying to do. Indeed my service does contain the "controller" logic itself.
So how do I get ETW to keep my trace session for the next reboot? Or alternatively how do I re-create my ETW session on the next reboot without overwriting the ETW file if its already there?
Related
I need to write a C++ application that should read firewall status of Windows, and then need to keep an eye continuously if admin/someuser
changes the firewall status (lets say when my program was started firewall was disabled and after sometime Admin enabled it).
To implement this, I have created a thread that periodically(10 seconds) poll the code that checks Windows firewall status, but this doesn't look an efficient solution to me as continuous polling is required.
Is there a way to get event automatically in my program if firewall status changes (for example, FindFirstChangeNotification, using this I can get notification if any change in directory)? This will avoid continuous polling and will make program more efficient I think.
Any help is appreciated.
I know there is Windows ETW which anti-viruses use and which has all the info you need. It is a big system log where you subscribe to log/event providers. Pretty much everything that happens in system gets reported there via event which you can listen/wait for. I don't know the links to more useful pages with a list of loggers connected to ETW so here is the more general page: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/event-tracing-for-windows--etw-. You need to find out how to use C++ ETW API and the name/ID of the firewall events provider with a list of event types, then using API subscribe to this provider and setup a callback for when an event that interests you (here change of firewall status) occurs and that is it.
I'm developing a custom credential provider and need to know at runtime if the scenario is a login or an unlock of the session. For this, I check the CREDENTIAL_PROVIDER_USAGE_SCENARIO returned by the SetUsageScenario of the ICredentialProvider interface.
On Windows 10, independently if I'm at login or when the session is locked, I always get CPUS_LOGON as usage scenario, while on previous version of Windows, CPUS_UNLOCK_WORKSTATION was returned when the session was locked and CPUS_LOGON at the login.
So it seems that changes appeared since Windows 10 that are not reported on MSDN.
Is there any other way to detect if the usage scenario is a session locked?
I am currently investigating the same issue and may have a work around until Microsoft can update the documentation.
Although I still receive a CPUS_LOGON, we are still inside the same session as the locked user. By using the function WTSQuerySessionInformationW, you can verify that there is currently a user logged in to the current session. From there, you can proceed as if you were in a CPUS_UNLOCK_WORKSTATION usage scenario.
UPDATE (1/18/2016): It seems Microsoft has finally updated their documentation on this issue. See the excerpt below from the CREDENTIAL_PROVIDER_USAGE_SCENARIO documentation:
Starting in Windows 10, the CPUS_LOGON and CPUS_UNLOCK_WORKSTATION
user scenarios have been combined. This enables the system to support
multiple users logging into a machine without creating and switching
sessions unnecessarily. Any user on the machine can log into it once
it has been locked without needing to back out of a current session
and create a new one. Because of this, CPUS_LOGON can be used both for
logging onto a system or when a workstation is unlocked. However,
CPUS_LOGON cannot be used in all cases. Because of policy restrictions
imposed by various systems, sometimes it is necessary for the user
scenario to be CPUS_UNLOCK_WORKSTATION. Your credential provider
should be robust enough to create the appropriate credential structure
based on the scenario given to it. Windows will request the
appropriate user scenario based on the situation. Some of the factors
that impact whether or not a CPUS_UNLOCK_WORKSTATION scenario must be
used include the following. Note that this is just a subset of
possibilities.
The operating system of the device.
Whether this is a console or remote session.
Group policies such as hiding entry points for fast user switching, or interactive logon that does not display the user's last name.
Credential providers that need to enumerate the
currently user logged into the system as the default tile can keep
track of the current user or leverage APIs such as
WTSQuerySessionInformation to obtain that information
If you turn fast user switching off, you will get the CPUS_UNLOCK_WORKSTATION messages upon locking. Otherwise you will only receive CPUS_LOGON. If you manually lock the PC using the windows API call from code to lock with fast user switching turned on, it will lock sending CPUS_UNLOCK_WORKSTATION and then immediately log off sending CPUS_LOGON.I Hope this helps, i don't have the reputation score to post an answer of my own so i edited this comment.
You might try SENS (System Event Notification Service). This is a Microsoft provided notification service.
https://msdn.microsoft.com/en-us/library/windows/desktop/cc185680(v=vs.85).aspx
It has different events for logon/logoff and screen lock/unlock notifications. It uses a COM+ interface. I am not familiar with the requirements of credential providers so I don't know if the service will run within the context you require or if the timing of the event arrival will meet your needs but it is something you might investigate.
Of all the answers, Justin's one is the more informative one, but nobody provides a workaround to properly restore the Windows7 behavior. Scott's answer mentions turning off Fast User Switching, but that turns off a feature that is available in Windows7, making it not a proper workaround. After carefully reading all the information available and several attempts, I found the following policies that allows only the previous logged user to unlock the machine, hence forcing the LogonUI framework to issue CPUS_UNLOCK_WORKSTATION scenario, but still allowing fast user switch:
Windows Registry Editor Version 5.00
; Computer Configuration -> Windows Settings -> Security Settings ->
; Local Policies -> Security Options "Interactive logon: Do not display last user name"
; Set to "Enabled": asks to unlock the machine only to currently logged user
; https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-display-last-user-name
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"dontdisplaylastusername"=dword:00000001
; Computer Configuration -> Administrative Templates -> Windows Components ->
; Windows Logon Options -> "Sign-in last interactive user automatically after a system-initiated restart"
; Set to "Enabled": Prevents last signed user to log in and lock automatically
; after a restart
; https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/winlogon-automatic-restart-sign-on--arso-
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"DisableAutomaticRestartSignOn"=dword:00000001
; Similar in bevahior to "dontdisplaylastusername" but also disables Fast User
; Switching, which was available in Windows7
; https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-windowslogon#windowslogon-hidefastuserswitching
;[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
;"HideFastUserSwitching"=dword:00000001
I'm have written a C++ application that is running as a Windows service to limit the volume of a Windows 7 computer. The user can specify different rules for different days and times and the service will smoothly change the volume. To implement this I use the IAudioEndpointVolume interface. In general it works like intended...
However, there exists a strange behavior I cannot explain yet. When switching users the volume suddenly drops but it does not generate a notification as one would expect. What is also strange is that the sliders in the SndVol.exe show the correct value for the volume.
Because of the missing notification my program cannot react to this change and as a result it cannot perform its intend anymore.
I have discovered that the volume will switch back to its correct volume again if I move the volume slider a bit. Of course this generates a notification that will be handled by my service. My service will then force the correct volume.
I don't understand why the volume changes without being visible in SndVol.exe and without creating a notification. Switching back to the first user account does not solve the problem. Even after logging out the volume is still at the wrong level.
As far as I have seen the documentation about the IAudioEndpointVolume interface does not mention anything about different user session.
Any ideas on what might cause this problem or what I could try to fix it?
Your service runs in session 0, the isolated session that prevents malware from exercising shatter attacks. The user's desktop runs in another session, there can be multiple. The WASAPI documentation is silent about exactly how an audio session gets mapped across Windows sessions. You have a very strong hint that it doesn't from the way it behaves.
There are ominous words in the section that talks about grouping parameters. A construct that primarily exists to allow Sndvol to identify processes that share the same volume control. It quotes Explorer as an example, a process that can be started more than once but still has a single volume control. A process that doesn't want to share uses session identifier GUID_NULL to select the default session in IAudioSessionControl::SetGroupingParam() or simply omits the call altogether since that's the default.
And the behavior of Sndvol, it only displays volume controls for the processes that run in the desktop session. You can't see the processes in another desktop session. Giving a very strong hint that audio session GUID_NULL is specific to the session in which it got created.
So quite unlikely that you can find a workaround for it as long as you do this with a service.
Instead, consider running your program as a normal windowless process that runs in the user's desktop session. Getting started by the Run registry key or a Startup folder shortcut or the task scheduler.
Well, after some time I am now quite confident that the volume change is caused by the 3rd party driver we are using. This driver has it's own volume control mechanism. I do not experience the change anymore after just starting the drivers' control GUI. Even after a restart the problem seems to be fixed. However, after some time it gets broken again for a reason I cannot figure out. But this only happened because some security settings prevented the drivers' control GUI to start when logged in as non admin. I fixed this now and expect everything to work now.
Furthermore it looks like that all user sessions share the same volume control. That means if I change the volume with SndVol in one user session the same change happens in the other user session. My service receives notifications for all these changes. So it looks like that I did not receive a notification when switching between users because the change was caused by the driver's control GUI starting when logging in as administrator. But this change happened in the driver, a lower layer, so that Windows is not aware of the change.
The driver we are using is the kX Audio Driver.
I want to write a C++ application that collects information about user logons/logoffs for Windows XP. I've done some searching around and have yet to find a viable way of doing this. There doesn't appear to be a system call I could use. I could export the log file from Event Viewer and use I/O operations but the code would be relying on the assumption that someone exported the log file. Is it realistically possible to write a C++ application to collect information about user logons? I'm using MinGW.
This could be done by using an application that starts before anyone logs into the system and runs all the time, regardless of users logging in and out. That is to say, a Windows service.
Windows services have the ability to detect and react to session changes via the OnSessionChange event handler.
Happy hunting!
I have a service application that on startup and shutdown logs an event log record.
I rebuild the application frequently and also then the executable on the host machine. And here is the problem, after my service shutdown the Windows Eventlog service (not the event log viewer) is holding an open handle to the executable so I cant update it.
I have the event log messages embedded in the executable, i could move it out but then I just move the update problem to another file.
I've double checked and I have paired ::RegisterEventSource/::DeregisterEventSource correctly.
Anyone encountered this problem ?
I've also run into this issue, so just adding some of my experiences.
I have a Windows 2008 Service system (have not seen this on 2003 Server), and when I stop my service, and instance of svchost.exe loads the service executable (visible using vmmap.exe or Process Hacker) preventing it from being deleted/overwritten during uninstall/install. The instance of svchost.exe is running the DHCP Client (Dhcp), TCP/IP NetBIOS Helper (lmhosts), and Windows Event Log (EventLog) services.
In our case, we have created a registry entry to make our service executable an event source. (though I'm unsure exactly why we are doing this, or whether we should be doing this).
Empirically, if I remove that registry entry before stopping the service, the executable is not loaded by svchost.exe and all is fine. If the service has already been stopped and executable loaded by svchost.exe, restarting the Event Log service (or killing the process) also frees up the executable.
I'm guessing our service is not well-behaved (perhaps a side effect of being a 32-bit process on 64-bit OS?) or correctly installed, but haven't isolated the issue yet.
Update: It appears this issue is only happening on HP systems (and not Dell or IBM) which is curious. There are HP-specific management components installed, so perhaps one of them is altering the behavior somehow?
I've also run into this issue. In my case, nxlog service reading logs. Simply stop nxlog service before replace event source file.
I think it is probably the event log viewer. Close the viewer and you'll be fine.