Hi I wanted to debug login delay
I can see eventvwr event like following that took around 50-60 secs to complete.
The winlogon notification subscriber <Profiles> finished handling the notification event (2).
Not able to make out which is the process/exe that subscribed for this event, so that I can focus to specific process activities in wpr traces.
If I can check some cmd what subscribers registered for winlogon using some tool or cokmmand that will definitely help
Related
tldr Why don't I receive PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMESUSPEND, and PBT_APMSUSPEND as the payload to service events of type SERVICE_ACCEPT_POWEREVENT?
I'm trying to detect when a windows device as woken back up from sleep. I have a constellation of processes that interact via IPC, which includes both UI applications with an event handler function provided to RegisterClassEx and services using RegisterServiceCtrlHandlerExW.
My preference is to receive these events in a service. My understanding is that I can get SERVICE_ACCEPT_POWEREVENT in dwControlsAccepted, and can then distinguish specific kinds of power event by looking at the dwEventType parameter, as per these docs https://learn.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex. However, I only ever receive PBT_APMPOWERSTATUSCHANGE, corresponding to fiddling with the power cord on the laptop. I expected to also receive some combination of PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMESUSPEND, and PBT_APMSUSPEND.
When testing on the UI side, I do get WM_POWERBROADCAST events of any kind. Obviously I've missed some part of setup there. Again, the process that actually needs this info is a service, so I would have to IPC the event to a service if this is what ended up working.
For full credit, I also experimented with SERVICE_CONTROL_CONTINUE and SERVICE_CONTROL_PAUSE (enabled via SERVICE_ACCEPT_PAUSE_CONTINUE), but never receive these events at all. I had expected those to correlate with sleeping the laptop but apparently not.
My app needs to keep receiving data from BLE devices when the user hits the side button and "kill" the app or it simply run in sleep mode. How can I save the state of my app and his listeners so I can keep receiving the data?
I've read some approaches but I want to know what is the one more indicate.
Launch a service as the center of my app?
Launch pendingIntent so the user can re-enter the app after sleep mode? In this case how can I keep my listeners for receiving data?(service?)
Your app can implement a WearableListenerService; framework will instantiate it when you have a message/data and calls its appropriate callbacks with the message or data that has arrived.
The solution I've implemented was the first one!
I've completely detached the center of my app from the UI activity and implemented a service as the "brain". The service and the activity are in constant communication through a broadcast channel. When the smartwatch is in sleep mode I launch a pendindIntent (card) so the system can recover to the main activity.
That's how I've done it, hope it helps someone else!
I am doing some POC's in tibco general palletes and came across onEventTimeout.By reading the docs it says
The On Event Timeout process starter specifies a process to execute when a Wait For ... activity discards an incoming event due to a timeout. A Wait For ... activity’s event timeout is specified by the Event Timeout field on the Event tab of the activity.
So I created one process definition having start,wait and end activity.Then created another process definition and added oneventtimeout starter process from the general activities.Now when I click on event source browse button(binocular icon) then it does not show me the above process definiton(having wait activity).So I guess I may be missing something.
Can any body please tell me how to use it ?
The onEventTimeout process starter will not work with a Wait activity. Try using a "Wait for" type of activity instead, for instance Wait for JMS Queue Message.
I have a program that reacts to WM_QUERYENDSESSION to perform some cleanup running as a scheduled task. Logging indicates that the cleanup code is not executed. Do applications running as a scheduled task receive WM_QUERYENDSESSION messages or is there any other way to detect Window shutdown?
The messages are sent to top level windows. If your process has one, it will be sent the message. If you don't have one, then you can create one for that purpose. If your application is a console application then SetConsoleCtrlHandler is the recommended way to receive such notification.
It transpires, from the comment thread, that your process is running under the SYSTEM account. According to the documentation, this means that it will not be shutdown by the system.
Applications running in the system security context do not get shut down by the operating system. They get notified of shutdown or logoff through the callback function installable via SetConsoleCtrlHandler.
I am in support of an application that involves serial port communication.
There are 32 MSComm controls (control array) on the form.
Suppose data arrived at one of the com port while some other code of the same thread is running (say database access etc.). will the Oncomm event procedure queed for execution or the current execution point is queed and Oncomm event handler is executed?
VB6 is single threaded. Basically (excepting ActiveX controls for a second) there's just the GUI thread.
It's sitting there waiting for an event. You get data, so it enters the event handler for your MSComm control and starts doing some database access. It blocks waiting for the database to respond. Another MSComm control receives data and fires off an event. This event just sits in the Windows event queue. The GUI thread has to exit the event handler before it can process the other MSComm event.
Of course, in the middle of an event handler you can call DoEvents. I highly suggest you rarely, if ever, do that. It's the source of many difficult bugs, in my experience.
There are ways to queue the long running database work onto a background thread (using a call into .NET managed code, in that case). That will allow your event handler code to continue almost immediately without blocking, allowing it to process the next message. To my knowledge, there's no native VB6 way to do that.