Open tianxiayu007 opened 4 years ago
That is odd; your configuration changes should not have an effect on explorer.exe; but perhaps the default configuration does. You may try setting Config_autoSaveSession=off
, which deactivates the possibility for a session restore, but also spares bug.n from saving the information.
That is odd; your configuration changes should not have an effect on explorer.exe; but perhaps the default configuration does. You may try setting
Config_autoSaveSession=off
, which deactivates the possibility for a session restore, but also spares bug.n from saving the information.
can you reproduce it with my config?
may be Config_verticalBarPos=bottom
cause this problem, when i set value to 'top' or 'tray',this won't happen again, but why is this?
what version of Windows 10 are you using? Looks like beta...
win+R > cmd "enter" > ver "enter"
ex: "Microsoft Windows [Version 10.0.18363.778]"
what version of Windows 10 are you using? Looks like beta...
win+R > cmd "enter" > ver "enter"
ex: "Microsoft Windows [Version 10.0.18363.778]"
it says [Version 10.0.19041.207]
This issue reminded me of #229 but I do not have any clue.
I did some testing with bug.n 9.0.2 on Windows 10 Build 18363.778, but could not reproduce the issue here; Windows-Explorer only went up in CPU usage when being opened and indexing the directory; with nothing been done CPU is below 2%.
But funnily I could reproduce issue #229. The whole desktop was messed up to being unusable.
I will have to wait until I get build 10.0.19041.207 on my device to try again.
I did some testing with bug.n 9.0.2 on Windows 10 Build 18363.778, but could not reproduce the issue here; Windows-Explorer only went up in CPU usage when being opened and indexing the directory; with nothing been done CPU is below 2%.
But funnily I could reproduce issue #229. The whole desktop was messed up to being unusable.
I will have to wait until I get build 10.0.19041.207 on my device to try again.
ok,it's not a problem if i don't use above config. Win10 inside preview(slow channel) currently works well, I suggest you upgrade if necessary
I get the same problem with a completely fresh install of bug.n v9.0.2 and AutoHotKey v1.1.32.00 on Windows 10 Pro version 1909 build 18363.778.
I tested the same virgin AutoHotKey and bug.n install on Windows 10 Pro version 1909 build 18363.815 and saw the same problem.
It completely freezes Windows Explorer which means that even the Start Menu does not work. I found it also crashes Microsoft Outlook.
Even after quitting bug.n, the Start Menu (pressing the Windows key) is unresponsive, so I have to Sign Out of my Windows login and sign back in again to get Explorer working.
I can't use bug.n due to this issue.
Found my way here after finding out my explorer.exe, taskbar, and start menu hanging was caused by the bug.n development branch. Win10 Pro version 1909 build 18363.720.
I've been using the standalone bug.n 9.0.2 without any major issues for almost a year now, but I tried the latest master branch this week because it fixes a multi-monitor DPI scaling issue that's been bugging me for a while.
Though I didn't have problems for a few days, I started getting the following issues:
Killing the AutoHotkey process brings things back to normal after around 10 seconds. Killing explorer.exe instead doesn't reopen it or fix any of the issues above, so I'm forced to restart.
It doesn't seem related to custom configs, because I still get the issue when commenting out my entire config. Went back to 9.0.2, and everything seems fine again.
bug.n seems to working fine now. I'm still using the same completely fresh install of bug.n v9.0.2 and AutoHotKey v1.1.32.00 on Windows 10 Pro (which has been updated to version 2004, OS build 19041.388)
OS: Microsoft Windows [版本 10.0.19041.207] config as follow:
what i changed compare with default config just is:
and when i run bug.n, explorer.ext stop responding as image below: