-
Notifications
You must be signed in to change notification settings - Fork 46
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
.NET Exception Errors #58
Comments
This is a known problem and I'm working on a fix. I don't have a lot of time on my hands at the moment, so it still might take some time until a fix is ready. If this error message is too distracting, try downgrading to an older version and see if this helps |
Thanks Jonas, good to hear that you're aware of the issue. |
Just to let you know that I have the same issue with CLI 3.8.0.1, the Microsoft NET framework error would pop up every once in a while, closing the window or clicking on Continue would fix the issue. I downloaded CLI 3.8.0.0 and so far, the error seems to be gone. |
Should be fixed in 3.9.0.0. If not, please reopen. |
@jonaskohl I looked around and it looks like you can try moving e.Cancel = true; on line 521 in MainForm.cs to the top of the HideForm() function as it seems that it might not be getting set when some other methods call HideForm(). This apparently stops memory being freed which should stop the object not being able to be called sometimes. Where I got the info: https://stackoverflow.com/a/6993454 Although it seems like you need to pass eventargs to HideForm() which I'm not sure will work correctly, I'm away from a Windows computer at the moment, I'll try to make changes, but it'll take time. |
@Yetoo1 Thank you for your effort. I will take another look at this tomorrow. I am also going to reopening this issue again. |
@jonaskohl I played around with commenting out lines 63 - 91 in IndicatorOverlay.cs and one time during that testing. What that does is mess with the way the overlay loads and puts a raw form (no size change or borders (not sure about latter)) if one of the lock keys is pressed if an overlay isn't currently fading. I compiled a change involving that and hit capslock simultaneously along with some lag from the compile when it loaded and it seems to have crashed on SetOpacity(op) (line 271). There may be a race condition with SetLayeredWindowAttributes as that's the only function in SetOpacity. The behavior of the opacity didn't seem to change if I moved the function call below line 287, but I wasn't able to reproduce the crash with SetOpacity below or above it either. This may have to do with SetOpacity in fadeTimer_Tick and maybe some tick gets evaluated before another tick should and confuses SetLayeredWindowAttributes with a value higher than 255 and crashes on the next update, but I doubt it. https://stackoverflow.com/a/9727364 may help. Let me know your thoughts on this issue. |
I took a second look at it and I reproduced @Yetoo1's fixes. I didn't get the error message for now, though this doesn't necessarily mean anything, as I find it hard to reproduce the error consistently and I didn't find a way to trigger it manually. It always seems to occur at random. I'll push out a fix in a bit, hoping the issue has been resolved, but I'll leave this issue open for now until I am certain the issue has been fixed. |
I updated it to 3.9.1 from 3.7.3 and it shows the dialog box, here are details:
|
I was playing tf2 and I don't think I pressed any of the lock keys and I got the error: ************** Exception Text ************** ************** Loaded Assemblies **************
|
I'm now using 3.9.1.0, and fingers crossed things look good, I haven't seen the crash again yet! |
@jonaskohl Try creating another branch and move setopt in UpdateIndicator back up to where it was (below lastopacity) and move lines 219 to 222 (including clickthroughwindow) in IndicatorOverlay(string content,... to line 209 under setopacity. I would have said to move setopacity down below the if else, but I crashed immediately (although I lagged a lot due to slow computer before that). Don't update it yet, but leave it open in debugging mode from visual studio to see if it happens again. @ratajs @DaveH1 Please provide your system info. (Model, Processor model, how much ram, os version and os build number (winver), 32 or 64 bit os install, integrated or dedicated video card, hard drive or ssd) My system info: |
Well for what it's worth the system I'm using CLI on, as it has no caps lock indicator light, is a very underpowered Asus netbook, a X102B(A). It was originally designed for Windows 8, and isn't really up to running that very well, mainly because it has a rubbish 1GHz 2 core AMD processor! It does have 4GB of RAM fitted, a lot of which is eaten up by the on-board graphics system. Although it's a 64 bit system, I'm running 32 bit Windows 10 on it, version 20H2 (19042.685). It does now have an SSD fitted, which helped a bit to speed it up, but it's still pretty slow, although it's actually better with Windows 10 than it was with Windows 8.1! I keep it because of its small size, and it's still architecturally and physically a proper PC, not a tablet or convertible, with a touchscreen. |
@jonaskohl What is the purpose of setting opacity to 1d in ClickThroughWindow? |
@Yetoo1 I have ASUS F556UQ-DM953T with Intel i7 7500U, 8 GB of RAM, 1TB HDD and dedicated 940MX graphic card. Windows version is 10 Pro 20H2, 64 bit, OS build 19042.685. |
Only shows overlay indicator if this.IsDisposed is false in SetOpacity() and ClickThroughWindow(). Shows overlay in IndicatorOverlay() in IndicatorOverlay.cs so check is cleaner.
I don't think I solved the issue of the IndicatorOverlay being disposed too soon, but I was able to work around it by checking for IsDisposed in ClickThroughWindow(). I was able to reliably increase the chances of the error coming up by starting Steam fresh (exiting if already open), launching TF2, loading ctf_2fort, quit via console, and then exiting steam and pressing capslock in each of these steps. I went through this process 2 times with this fix and I didn't get any crash messages at any of the times I did with other iterations of the troubleshooting. I think it has to do either with lag due to very slow loads due to disk speed on my system or something to do with some proprietary library Steam or TF2 uses that somehow affects thread timing. I forgot if I tested it, but I think simply doing IsDisposed in IndicatorOverlay before everything isn't good enough because then you would need to not run the SetOpt and ClickThroughWindow functions due to that condition (I'm starting to doubt it's the problem here, definitely early on in troubleshooting, but less so after reliably getting it to crash in ClickThroughWindow, but I could be wrong) and can mess up (threads maybe) the final show until the next cycle. I'm tired at the moment so let's just say we keep the IsDisposed in both SetOpt and IndicatorOverlay for assurance since we still don't know what's causing it exactly. Since we are catching IsDisposed, it shouldn't stop the program so the next lock key press should succeed and look like nothing happened to the end user if they didn't notice the overlay not popping up for the one key press (I think this is the behavior). |
@jonaskohl I found some potential issues that my PR doesn't address. SetOpacity has an arithmetic exception due to some race condition in fadeTimer_Tick that caused the result of opacity_timer_value * lastOpacity to overflow and then caused the aforementioned arithmetic exception. This seems to be either indirect or separate from whatever is causing the handle to be disposed. I found that creating a mutex lock and sleeping for 1 millisecond in fadeTimer_Tick reproduced the arithmetic exception every time or at least when stepping through it every time. Checking that opacity_timer_value in fadeTimer_Tick doesn't go below 0.0 seems to have resolved that issue. To be clear, I am no way an expert in thread nor C# threading. From what I've been able to gather, it seems that the Close(); function in WindowCloseTimerTick seems to be screwing things up. I've tried getting some kind of on/off bool so that ShowOverlay is able to check it and close the overlay appropriately so it bypasses the tick/threading system but it seems like the switch keeps getting messed up by it as well due to the bool still being assigned in the problem areas of IndicatorOverlay. I will do a couple of tests and see if the mutex will work around the close statement, but just giving an update. |
@jonaskohl Adding a mutex for Close() didn't work. I don't have the time now, but it definitely seems like the threading structure needs to be reworked with Forms timers being replaced with custom threading timers or the close needs to be refitted with something that passes FormClosingEventArgs like https://stackoverflow.com/a/6993514 demonstrates and Hide() and Show() accordingly. |
Hi again! |
I created an issue the other day that I now think is related to this, so my crash report details are listed there, feel free to close it if it's the same thing, and let me know if you need any other details. "Please provide your system info. (Model, Processor model, how much ram, os version and os build number (winver), 32 or 64 bit os install, integrated or dedicated video card, hard drive or ssd)" Lenovo T14s |
I hope I (finally) fixed this in version 3.10.0.0. Please let me know if anyone of you is still experiencing this bug after updating. |
@jonaskohl I got this bug after caps locking after new installation: https://p.bsd-unix.net/view/d79161fc I had to do a new install because I got a .net error when I clicked restart after downloading the update through the cli client: This seems to be an issue due to a thread wanting to open when it the handle it's trying to use was previously closed (thus memory freed) by another thread. |
Alright, I'm troubleshooting again and doing if (!indicatorOverlay.IsDisposed) before indicatorOverlay.Show(); in ShowOverlay in MainForm.cs (
Pending... |
Hi Jonas, thanks for the new version, but as has been said, the error is still there I'm afraid. |
@jonaskohl So I added if (!indicatorOverlay.IsDisposed) before
|
It still happens sometimes. |
Windows 8.1 / 3.10.0.0 threw it again today, running as administrator. |
Happening far less since the update, but just had it crash again on W10:
|
I have just released version 3.11.0.0. I have changed a lot about how the overlay is shown. Please let me know if this fixes the issue. |
Thanks Jonas, it's looking good so far! |
Just updated to 3.11.1.0, and the update system is still crashing. |
Okay, but this exception is different than the randomly occuring one. This one refers to a file to not be found. This may be related to #84 |
Ah thanks Jonas, the #84 issue reported does indeed look like it was almost certainly the problem. |
At the risk of jinxing it, so far so good. I don't think it's crashed once since the last update. That said, I just tried testing it as I type this and found the notifications isn't showing. :( Before I restart it to see if that fixes it, is there anything I should do, e.g. a log I can check? |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically closed because there has not been any new activity since it has been marked as stale. |
Hi again Jonas!
I've been using the new version of CapsLockIndicator for a while now (3.8.0.1) and it works great most of the time, but sometimes when I use it it pops up a .NET exception error message, which says "Cannot access a disposed object".
I have absolutely no idea what that actually means!
If I tell it to continue, it carries on fine.
Any idea why that might be?
Cheers,
Dave Hawley.
The text was updated successfully, but these errors were encountered: