Originally created by @Fydon on GitHub (May 28, 2024).
Describe the bug
Since updating from v0.1.25 to v0.1.26, I've had Norton 360's Data Protector notify me 8 times that it blocked a suspicious action by komorebic.exe. The target file path always starts with C:\ProgramData\Microsoft\Windows\WER\:
I've tried to look for more details, but haven't managed to find any yet.
To Reproduce
Not sure
Expected behavior
Screenshots and Videos
Operating System
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22631 N/A Build 22631
komorebic check Output
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\username
Looking for configuration files in C:\Users\username
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\username\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag
Additional context
I'm not running AHK scripts or any other software to handle any aspect of window management or manipulation
Originally created by @Fydon on GitHub (May 28, 2024).
**Describe the bug**
Since updating from v0.1.25 to v0.1.26, I've had Norton 360's Data Protector notify me 8 times that it blocked a suspicious action by komorebic.exe. The target file path always starts with `C:\ProgramData\Microsoft\Windows\WER\`:
* C:\ProgramData\Microsoft\Windows\WER\ReportQueue\NonCritical_komorebi.exe_628cd55635906b21e1f318735447494e533751ba_00000000_14a0ecde-8625-4b48-8f07-8067ec910150\Report.wer"
* C:\ProgramData\Microsoft\Windows\WER\ReportQueue\NonCritical_komorebi.exe_a01689e91534f33411526667386967bb39c26933_00000000_cab_7e37d60c-243a-4463-a1d4-d40ae5fbfc4a\WER.d5a156e6-ede2-43cc-be95-f46f766f871c.tmp.WERInternalMetadata.xml"
* C:\ProgramData\Microsoft\Windows\WER\Temp
* C:\ProgramData\Microsoft\Windows\WER\Temp\14a0ecde-8625-4b48-8f07-8067ec910150
* C:\ProgramData\Microsoft\Windows\WER\Temp\2018d40a-4a63-4b83-93c7-debeef8e2e4d
* C:\ProgramData\Microsoft\Windows\WER\Temp\785b3b3e-0e94-48a9-9d2e-dde0a3e74907
* C:\ProgramData\Microsoft\Windows\WER\Temp\7e37d60c-243a-4463-a1d4-d40ae5fbfc4a
* C:\ProgramData\Microsoft\Windows\WER\Temp\d67637ee-65d0-4e85-ac8d-3315f15e49e9

I've tried to look for more details, but haven't managed to find any yet.
**To Reproduce**
Not sure
**Expected behavior**
**Screenshots and Videos**
**Operating System**
```
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22631 N/A Build 22631
```
**`komorebic check` Output**
```
No KOMOREBI_CONFIG_HOME detected, defaulting to C:\Users\username
Looking for configuration files in C:\Users\username
Found komorebi.json; this file can be passed to the start command with the --config flag
Found C:\Users\username\.config\whkdrc; key bindings will be loaded from here when whkd is started, and you can start it automatically using the --whkd flag
```
**Additional context**
I'm not running AHK scripts or any other software to handle any aspect of window management or manipulation
adam
added the bug label 2026-01-05 14:50:21 +01:00
I guess this is something at the OS level or maybe a result of installing with WinGet, because komorebi and komorebic have not explicitly opted in to Windows Error Reporting 🤔
@LGUG2Z commented on GitHub (May 29, 2024):
https://learn.microsoft.com/en-us/windows/win32/wer/windows-error-reporting
I guess this is something at the OS level or maybe a result of installing with WinGet, because `komorebi` and `komorebic` have not explicitly opted in to Windows Error Reporting 🤔
Now that I come to think of it, I'd installed 0.1.24 and 0.1.25 with the MSI, but 0.1.26 was probably the first I installed with winget. Therefore maybe it is something to do with that.
@Fydon commented on GitHub (May 29, 2024):
Now that I come to think of it, I'd installed 0.1.24 and 0.1.25 with the MSI, but 0.1.26 was probably the first I installed with winget. Therefore maybe it is something to do with that.
Thanks for grabbing this information! It looks like I was missing a few calls to DeleteObject before - I've added these in which should resolve the GDIObjectLeaks from the border manager at least; I'll need to take a look and see if we need to do something similar for the stackbar manager.
@LGUG2Z commented on GitHub (May 29, 2024):
Thanks for grabbing this information! It looks like I was missing a few calls to [DeleteObject](https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-deleteobject) before - I've added these in which should resolve the GDIObjectLeaks from the border manager at least; I'll need to take a look and see if we need to do something similar for the stackbar manager.
Found some in the stackbar manager too which I've addressed above ^
This doesn't really address the Norton issue (not sure there is anything we can do for overzealous AV software) - but the info in this issue has definitely helped us improve the correctness of komorebi 🎉
@LGUG2Z commented on GitHub (May 29, 2024):
Found some in the stackbar manager too which I've addressed above ^
This doesn't really address the Norton issue (not sure there is anything we can do for overzealous AV software) - but the info in this issue has definitely helped us improve the correctness of komorebi 🎉
Thank you for the quick response. I think the next release will resolve it for now. If it happens again I'll know to check event viewer for more information.
@Fydon commented on GitHub (May 29, 2024):
Thank you for the quick response. I think the next release will resolve it for now. If it happens again I'll know to check event viewer for more information.
Since installing the update, I haven't seen any popups from Norton or logs in Event Viewer about leaks, so I think that this is resolved. Thank you.
@Fydon commented on GitHub (Jun 26, 2024):
Since installing the update, I haven't seen any popups from Norton or logs in Event Viewer about leaks, so I think that this is resolved. Thank you.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Fydon on GitHub (May 28, 2024).
Describe the bug
Since updating from v0.1.25 to v0.1.26, I've had Norton 360's Data Protector notify me 8 times that it blocked a suspicious action by komorebic.exe. The target file path always starts with
C:\ProgramData\Microsoft\Windows\WER\:I've tried to look for more details, but haven't managed to find any yet.
To Reproduce
Not sure
Expected behavior
Screenshots and Videos
Operating System
komorebic checkOutputAdditional context
I'm not running AHK scripts or any other software to handle any aspect of window management or manipulation
@LGUG2Z commented on GitHub (May 29, 2024):
https://learn.microsoft.com/en-us/windows/win32/wer/windows-error-reporting
I guess this is something at the OS level or maybe a result of installing with WinGet, because
komorebiandkomorebichave not explicitly opted in to Windows Error Reporting 🤔@Fydon commented on GitHub (May 29, 2024):
Now that I come to think of it, I'd installed 0.1.24 and 0.1.25 with the MSI, but 0.1.26 was probably the first I installed with winget. Therefore maybe it is something to do with that.
@Fydon commented on GitHub (May 29, 2024):
Checking Event Viewer, I see the following for yesterday. It seems to be about a GDI object leak.
@LGUG2Z commented on GitHub (May 29, 2024):
Thanks for grabbing this information! It looks like I was missing a few calls to DeleteObject before - I've added these in which should resolve the GDIObjectLeaks from the border manager at least; I'll need to take a look and see if we need to do something similar for the stackbar manager.
@LGUG2Z commented on GitHub (May 29, 2024):
Found some in the stackbar manager too which I've addressed above ^
This doesn't really address the Norton issue (not sure there is anything we can do for overzealous AV software) - but the info in this issue has definitely helped us improve the correctness of komorebi 🎉
@Fydon commented on GitHub (May 29, 2024):
Thank you for the quick response. I think the next release will resolve it for now. If it happens again I'll know to check event viewer for more information.
@Fydon commented on GitHub (Jun 26, 2024):
Since installing the update, I haven't seen any popups from Norton or logs in Event Viewer about leaks, so I think that this is resolved. Thank you.