This solves my issue, thanks. I guess I won't have to go through a several month-long journey to patch it out myself. (But I still might, just for fun. Who knows.) I have adapted to not keeping this information in the password field, but I was still concerned about this bug because if I fat fingered the wrong field by accident, it would lock up my CPU for several minutes. With the quality check disabled for these entries, that is no longer an issue.
I posted 3 solutions. Did you read the second one? kill the thread making the calculation when the "edit entry" screen is exited (since it has nowhere to display the calculation anyway), It's a multithreaded program, and a thread is generated to calculate the complexity of a password. And keeps running even when the screen that will receive the output is closed. There is no reason for that thread to continue running when the screen is closed. And there is no reason for multiple such instances of...
Yes, I can also save it in the "notes" field. But that's a workaround. Keepass in its current form can still lock up machines due to the bug. That's not good and should be fixed. I'm only familiar with Github and Java, but if it's just a simple length check with a conditional statement wrapped around it (my first solution), I could probably figure out C#, C++, and Sourceforge, and fix it myself. I work full-time retail though, so it'd probably take me a while. I haven't written code in forever. (And...
Forgot to post my specs: Windows 10 Keepass 2.52 (64-bit) XSL Stylesheets - Installed Keepass LibC (1.x File Support) 1.40.1 - 0x01C2 Bug also existed in older versions, since I updated when I discovered it (in case it had been fixed already, and it had not)
Keepass locks up CPU when handling very large passwords