Mixing
PowerShell: how to unregister orphaned WMI events
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
The following block of code will generate 100 WMI event subscriptions. This particular case is just an example, and will write a string to a file (100 times) whenever a keyboard is plugged in:
$KeyboardQuery = "SELECT * FROM __InstanceCreationEvent Within 1 WHERE TargetInstance ISA 'Win32_Keyboard'"
for ($i = 0; $i -lt 100; $i++) {
Register-WmiEvent -Query $KeyboardQuery -Action {
"A keyboard was just inserted." >> ~event-log.txt
}
}
When this is executed in PowerShell, the process WmiPrvSE.exe consumes 30%-40% of the CPU. If the following is then executed, the event subscriptions are removed and WmiPrvSE.exe drops to a normal level of CPU usage or closes altogether:
Get-EventSubscriber | Unregister-Event
This all works as expected. However, if the PowerShell window is closed before running Get-EventSubscriber | Unregister-Event, WmiPrvSE.exe does not exit, and continues to consume 30%-40% of the CPU. When a keyboard is inserted, the string is no longer written to the file. If a new PowerShell window is opened, Get-EventSubscriber or Get-EventSubscriber -Force cannot find the event subscribers. If all instances of WmiPrvSE.exe are forcefully closed, they start again and continue to consume 30%-40% of the CPU. Even after logging out and back in, WmiPrvSE.exe continues to consume the CPU. The only way I have found to end these event subscriptions is to restart the computer.
How can I end the event subscriptions which were started in a previous PowerShell session?
Update
I discovered that the CPU usage by orphaned event subscriptions can be ended by triggering the event they're subscribed to, even though they do not seem to run the code in the action block after the PowerShell window has been closed. So in this case, plugging in a keyboard after closing PowerShell causes WmiPrvSE.exe to return to its normal behavior. It's like the event subscriptions are waiting for the event to be triggered one last time before they can be cleaned up, but are now owned by the WMI system itself.
powershell wmi wmi-query
asked Jan 3 at 3:40
jdgregsonjdgregson
831823
add a comment |
The following block of code will generate 100 WMI event subscriptions. This particular case is just an example, and will write a string to a file (100 times) whenever a keyboard is plugged in:
$KeyboardQuery = "SELECT * FROM __InstanceCreationEvent Within 1 WHERE TargetInstance ISA 'Win32_Keyboard'"
for ($i = 0; $i -lt 100; $i++) {
Register-WmiEvent -Query $KeyboardQuery -Action {
"A keyboard was just inserted." >> ~event-log.txt
}
}
When this is executed in PowerShell, the process WmiPrvSE.exe consumes 30%-40% of the CPU. If the following is then executed, the event subscriptions are removed and WmiPrvSE.exe drops to a normal level of CPU usage or closes altogether:
Get-EventSubscriber | Unregister-Event
This all works as expected. However, if the PowerShell window is closed before running Get-EventSubscriber | Unregister-Event, WmiPrvSE.exe does not exit, and continues to consume 30%-40% of the CPU. When a keyboard is inserted, the string is no longer written to the file. If a new PowerShell window is opened, Get-EventSubscriber or Get-EventSubscriber -Force cannot find the event subscribers. If all instances of WmiPrvSE.exe are forcefully closed, they start again and continue to consume 30%-40% of the CPU. Even after logging out and back in, WmiPrvSE.exe continues to consume the CPU. The only way I have found to end these event subscriptions is to restart the computer.
How can I end the event subscriptions which were started in a previous PowerShell session?
Update
I discovered that the CPU usage by orphaned event subscriptions can be ended by triggering the event they're subscribed to, even though they do not seem to run the code in the action block after the PowerShell window has been closed. So in this case, plugging in a keyboard after closing PowerShell causes WmiPrvSE.exe to return to its normal behavior. It's like the event subscriptions are waiting for the event to be triggered one last time before they can be cleaned up, but are now owned by the WMI system itself.
powershell wmi wmi-query
asked Jan 3 at 3:40
jdgregsonjdgregson
831823
add a comment |
The following block of code will generate 100 WMI event subscriptions. This particular case is just an example, and will write a string to a file (100 times) whenever a keyboard is plugged in:
$KeyboardQuery = "SELECT * FROM __InstanceCreationEvent Within 1 WHERE TargetInstance ISA 'Win32_Keyboard'"
for ($i = 0; $i -lt 100; $i++) {
Register-WmiEvent -Query $KeyboardQuery -Action {
"A keyboard was just inserted." >> ~event-log.txt
}
}
When this is executed in PowerShell, the process WmiPrvSE.exe consumes 30%-40% of the CPU. If the following is then executed, the event subscriptions are removed and WmiPrvSE.exe drops to a normal level of CPU usage or closes altogether:
Get-EventSubscriber | Unregister-Event
This all works as expected. However, if the PowerShell window is closed before running Get-EventSubscriber | Unregister-Event, WmiPrvSE.exe does not exit, and continues to consume 30%-40% of the CPU. When a keyboard is inserted, the string is no longer written to the file. If a new PowerShell window is opened, Get-EventSubscriber or Get-EventSubscriber -Force cannot find the event subscribers. If all instances of WmiPrvSE.exe are forcefully closed, they start again and continue to consume 30%-40% of the CPU. Even after logging out and back in, WmiPrvSE.exe continues to consume the CPU. The only way I have found to end these event subscriptions is to restart the computer.
How can I end the event subscriptions which were started in a previous PowerShell session?
Update
I discovered that the CPU usage by orphaned event subscriptions can be ended by triggering the event they're subscribed to, even though they do not seem to run the code in the action block after the PowerShell window has been closed. So in this case, plugging in a keyboard after closing PowerShell causes WmiPrvSE.exe to return to its normal behavior. It's like the event subscriptions are waiting for the event to be triggered one last time before they can be cleaned up, but are now owned by the WMI system itself.
powershell wmi wmi-query
asked Jan 3 at 3:40
jdgregsonjdgregson
831823
The following block of code will generate 100 WMI event subscriptions. This particular case is just an example, and will write a string to a file (100 times) whenever a keyboard is plugged in:
$KeyboardQuery = "SELECT * FROM __InstanceCreationEvent Within 1 WHERE TargetInstance ISA 'Win32_Keyboard'"
for ($i = 0; $i -lt 100; $i++) {
Register-WmiEvent -Query $KeyboardQuery -Action {
"A keyboard was just inserted." >> ~event-log.txt
}
}
When this is executed in PowerShell, the process WmiPrvSE.exe consumes 30%-40% of the CPU. If the following is then executed, the event subscriptions are removed and WmiPrvSE.exe drops to a normal level of CPU usage or closes altogether:
Get-EventSubscriber | Unregister-Event
This all works as expected. However, if the PowerShell window is closed before running Get-EventSubscriber | Unregister-Event, WmiPrvSE.exe does not exit, and continues to consume 30%-40% of the CPU. When a keyboard is inserted, the string is no longer written to the file. If a new PowerShell window is opened, Get-EventSubscriber or Get-EventSubscriber -Force cannot find the event subscribers. If all instances of WmiPrvSE.exe are forcefully closed, they start again and continue to consume 30%-40% of the CPU. Even after logging out and back in, WmiPrvSE.exe continues to consume the CPU. The only way I have found to end these event subscriptions is to restart the computer.
How can I end the event subscriptions which were started in a previous PowerShell session?
Update
I discovered that the CPU usage by orphaned event subscriptions can be ended by triggering the event they're subscribed to, even though they do not seem to run the code in the action block after the PowerShell window has been closed. So in this case, plugging in a keyboard after closing PowerShell causes WmiPrvSE.exe to return to its normal behavior. It's like the event subscriptions are waiting for the event to be triggered one last time before they can be cleaned up, but are now owned by the WMI system itself.
powershell wmi wmi-query
powershell wmi wmi-query
asked Jan 3 at 3:40
jdgregsonjdgregson
831823
asked Jan 3 at 3:40
jdgregsonjdgregson
831823
edited Jan 3 at 7:54
jdgregson
asked Jan 3 at 3:40
jdgregsonjdgregson
831823
asked Jan 3 at 3:40
jdgregsonjdgregson
831823
asked Jan 3 at 3:40
jdgregsonjdgregson
831823
831823
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
This is a potential duplicate of this Q&A.
Unregister-Event not removing orphaned event subscriptions
Quote from the post:
I had the same problem with a timer. I had somehow left a timer with
the same SourceIdentifier name in my PowerShell session. Whenever I
would wait for my 10 second timer, it would always return immediately.
I saved the output of the Wait-Event and could access the
EventIdentifier, which allowed me to Remove-Event by the
EventIdentifier. If I used the SourceIdentifier, I could not access
the orphaned event. I could tell it was orphaned by examining the
output of my Wait-Event.TimeGenerated, which was old. You will need to
be able to access the orphaned event by the EventIdentifier which is
unique.
Code from the post:
$eventDone = "Done"
$job2 = Register-ObjectEvent -InputObject $timer2 -EventName Elapsed -SourceIdentifier $eventDone
$timer2.Interval = 10000;
$timer2.AutoReset = $false;
$timer2.Enabled = $true;
$waitEvent = Wait-Event -SourceIdentifier $eventDone;
# Look at the $waitEvent.TimeGenerated for a clue it is old
# use the $waitEvent.EventIdentifier to access the event and remove it
$orphanEventID = $waitEvent.EventIdentifier
Remove-Event -EventIdentifier $orphanEventID
answered Jan 3 at 4:51
postanotepostanote
4,0822411
This sounds promising, but when I useRegister-WmiEventthe returned object doesn't have anEventId, it has aSubscriptionIdinstead. TheSubscriptionIdstarts at 1, and is only unique to that PowerShell session. If I close PowerShell and open a new window, the new window doesn't have any events with the same IDs from the last window, and throws an exception like the following if I try to look it up anyway:Get-EventSubscriber : Event subscription with identifier '1' does not exist.
– jdgregson
Jan 3 at 7:14
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54016050%2fpowershell-how-to-unregister-orphaned-wmi-events%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is a potential duplicate of this Q&A.
Unregister-Event not removing orphaned event subscriptions
Quote from the post:
I had the same problem with a timer. I had somehow left a timer with
the same SourceIdentifier name in my PowerShell session. Whenever I
would wait for my 10 second timer, it would always return immediately.
I saved the output of the Wait-Event and could access the
EventIdentifier, which allowed me to Remove-Event by the
EventIdentifier. If I used the SourceIdentifier, I could not access
the orphaned event. I could tell it was orphaned by examining the
output of my Wait-Event.TimeGenerated, which was old. You will need to
be able to access the orphaned event by the EventIdentifier which is
unique.
Code from the post:
$eventDone = "Done"
$job2 = Register-ObjectEvent -InputObject $timer2 -EventName Elapsed -SourceIdentifier $eventDone
$timer2.Interval = 10000;
$timer2.AutoReset = $false;
$timer2.Enabled = $true;
$waitEvent = Wait-Event -SourceIdentifier $eventDone;
# Look at the $waitEvent.TimeGenerated for a clue it is old
# use the $waitEvent.EventIdentifier to access the event and remove it
$orphanEventID = $waitEvent.EventIdentifier
Remove-Event -EventIdentifier $orphanEventID
answered Jan 3 at 4:51
postanotepostanote
4,0822411
This sounds promising, but when I useRegister-WmiEventthe returned object doesn't have anEventId, it has aSubscriptionIdinstead. TheSubscriptionIdstarts at 1, and is only unique to that PowerShell session. If I close PowerShell and open a new window, the new window doesn't have any events with the same IDs from the last window, and throws an exception like the following if I try to look it up anyway:Get-EventSubscriber : Event subscription with identifier '1' does not exist.
– jdgregson
Jan 3 at 7:14
add a comment |
This is a potential duplicate of this Q&A.
Unregister-Event not removing orphaned event subscriptions
Quote from the post:
I had the same problem with a timer. I had somehow left a timer with
the same SourceIdentifier name in my PowerShell session. Whenever I
would wait for my 10 second timer, it would always return immediately.
I saved the output of the Wait-Event and could access the
EventIdentifier, which allowed me to Remove-Event by the
EventIdentifier. If I used the SourceIdentifier, I could not access
the orphaned event. I could tell it was orphaned by examining the
output of my Wait-Event.TimeGenerated, which was old. You will need to
be able to access the orphaned event by the EventIdentifier which is
unique.
Code from the post:
$eventDone = "Done"
$job2 = Register-ObjectEvent -InputObject $timer2 -EventName Elapsed -SourceIdentifier $eventDone
$timer2.Interval = 10000;
$timer2.AutoReset = $false;
$timer2.Enabled = $true;
$waitEvent = Wait-Event -SourceIdentifier $eventDone;
# Look at the $waitEvent.TimeGenerated for a clue it is old
# use the $waitEvent.EventIdentifier to access the event and remove it
$orphanEventID = $waitEvent.EventIdentifier
Remove-Event -EventIdentifier $orphanEventID
answered Jan 3 at 4:51
postanotepostanote
4,0822411
This sounds promising, but when I useRegister-WmiEventthe returned object doesn't have anEventId, it has aSubscriptionIdinstead. TheSubscriptionIdstarts at 1, and is only unique to that PowerShell session. If I close PowerShell and open a new window, the new window doesn't have any events with the same IDs from the last window, and throws an exception like the following if I try to look it up anyway:Get-EventSubscriber : Event subscription with identifier '1' does not exist.
– jdgregson
Jan 3 at 7:14
add a comment |
This is a potential duplicate of this Q&A.
Unregister-Event not removing orphaned event subscriptions
Quote from the post:
I had the same problem with a timer. I had somehow left a timer with
the same SourceIdentifier name in my PowerShell session. Whenever I
would wait for my 10 second timer, it would always return immediately.
I saved the output of the Wait-Event and could access the
EventIdentifier, which allowed me to Remove-Event by the
EventIdentifier. If I used the SourceIdentifier, I could not access
the orphaned event. I could tell it was orphaned by examining the
output of my Wait-Event.TimeGenerated, which was old. You will need to
be able to access the orphaned event by the EventIdentifier which is
unique.
Code from the post:
$eventDone = "Done"
$job2 = Register-ObjectEvent -InputObject $timer2 -EventName Elapsed -SourceIdentifier $eventDone
$timer2.Interval = 10000;
$timer2.AutoReset = $false;
$timer2.Enabled = $true;
$waitEvent = Wait-Event -SourceIdentifier $eventDone;
# Look at the $waitEvent.TimeGenerated for a clue it is old
# use the $waitEvent.EventIdentifier to access the event and remove it
$orphanEventID = $waitEvent.EventIdentifier
Remove-Event -EventIdentifier $orphanEventID
answered Jan 3 at 4:51
postanotepostanote
4,0822411
This is a potential duplicate of this Q&A.
Unregister-Event not removing orphaned event subscriptions
Quote from the post:
I had the same problem with a timer. I had somehow left a timer with
the same SourceIdentifier name in my PowerShell session. Whenever I
would wait for my 10 second timer, it would always return immediately.
I saved the output of the Wait-Event and could access the
EventIdentifier, which allowed me to Remove-Event by the
EventIdentifier. If I used the SourceIdentifier, I could not access
the orphaned event. I could tell it was orphaned by examining the
output of my Wait-Event.TimeGenerated, which was old. You will need to
be able to access the orphaned event by the EventIdentifier which is
unique.
Code from the post:
$eventDone = "Done"
$job2 = Register-ObjectEvent -InputObject $timer2 -EventName Elapsed -SourceIdentifier $eventDone
$timer2.Interval = 10000;
$timer2.AutoReset = $false;
$timer2.Enabled = $true;
$waitEvent = Wait-Event -SourceIdentifier $eventDone;
# Look at the $waitEvent.TimeGenerated for a clue it is old
# use the $waitEvent.EventIdentifier to access the event and remove it
$orphanEventID = $waitEvent.EventIdentifier
Remove-Event -EventIdentifier $orphanEventID
answered Jan 3 at 4:51
postanotepostanote
4,0822411
answered Jan 3 at 4:51
postanotepostanote
4,0822411
answered Jan 3 at 4:51
postanotepostanote
4,0822411
answered Jan 3 at 4:51
postanotepostanote
4,0822411
4,0822411
This sounds promising, but when I useRegister-WmiEventthe returned object doesn't have anEventId, it has aSubscriptionIdinstead. TheSubscriptionIdstarts at 1, and is only unique to that PowerShell session. If I close PowerShell and open a new window, the new window doesn't have any events with the same IDs from the last window, and throws an exception like the following if I try to look it up anyway:Get-EventSubscriber : Event subscription with identifier '1' does not exist.
– jdgregson
Jan 3 at 7:14
add a comment |
This sounds promising, but when I useRegister-WmiEventthe returned object doesn't have anEventId, it has aSubscriptionIdinstead. TheSubscriptionIdstarts at 1, and is only unique to that PowerShell session. If I close PowerShell and open a new window, the new window doesn't have any events with the same IDs from the last window, and throws an exception like the following if I try to look it up anyway:Get-EventSubscriber : Event subscription with identifier '1' does not exist.
– jdgregson
Jan 3 at 7:14
This sounds promising, but when I use
Register-WmiEvent the returned object doesn't have an EventId, it has a SubscriptionId instead. The SubscriptionId starts at 1, and is only unique to that PowerShell session. If I close PowerShell and open a new window, the new window doesn't have any events with the same IDs from the last window, and throws an exception like the following if I try to look it up anyway: Get-EventSubscriber : Event subscription with identifier '1' does not exist.– jdgregson
Jan 3 at 7:14
This sounds promising, but when I use
Register-WmiEvent the returned object doesn't have an EventId, it has a SubscriptionId instead. The SubscriptionId starts at 1, and is only unique to that PowerShell session. If I close PowerShell and open a new window, the new window doesn't have any events with the same IDs from the last window, and throws an exception like the following if I try to look it up anyway: Get-EventSubscriber : Event subscription with identifier '1' does not exist.– jdgregson
Jan 3 at 7:14
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54016050%2fpowershell-how-to-unregister-orphaned-wmi-events%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
