Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explorer.exe autorestarting when "Automatically reformat pasted hashes in checker field" is enabled #142

Closed
DagiLajki opened this issue Aug 3, 2022 · 7 comments

Comments

@DagiLajki
Copy link

DagiLajki commented Aug 3, 2022

When entering app window not through direct context menu option but through tab in file properties...

while option "Automatically reformat pasted hashes in checker field" is enabled...

and i have some text in clipboard...

my Explorer.exe crashes and restarts...

Newest compilation of Win 11 Pro with all latest updates.

@namazso
Copy link
Owner

namazso commented Aug 3, 2022

Can you test if it occurs on latest development version? Sounds like a duplicate of #128

@DagiLajki
Copy link
Author

DagiLajki commented Aug 3, 2022

Nope... explorer.exe still crashing on 3.0.2-12-gdc18823

3 things must occur to eventual reproducing...

  1. some hash must be in clipboard (may be short)

  2. reformat option must be enabled

  3. entering through tab in properties (not directly from context menu)

@hgdagon
Copy link

hgdagon commented Aug 15, 2022

Can confirm same behavior on WIn11. Always crashes parent application, whether explorer or other.

@kurtmckee
Copy link
Contributor

Posting to add to the list of affected OS versions and to clarify hashes. This is not a "me too" post.

This crash behavior occurs on Windows 10 (version 21H2 build 19044.1889) as well.

@DagiLajki has correctly listed the requirements to cause the crash:

  1. A hash must be in the clipboard
  2. The option "Automatically reformat pasted hashes in the checker field" must be enabled
  3. You must go to the "Hashes" tab in the file properties.

For reference, the text in my clipboard was exactly 8f46453e68ef38e5544a76d84df3994c.

@namazso
Copy link
Owner

namazso commented Sep 16, 2022

I can confirm this issue, it's a stack overflow yet again, similar to what we had with the Microsoft STL's std::regex in #128 except it happens deeper because CTRE is better

@kurtmckee
Copy link
Contributor

@namazso Thank you for fixing this issue! And thanks for your work on OpenHashTab!

@kurtmckee
Copy link
Contributor

I've just encountered this issue while attempting to isolate and document a different possible bug. Would you be willing to release a new version of OpenHashTab that contains this fix?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants