A Viewer for Windows, ESP32 Projects, Cast, NotifyOnDemand, Push2Run and SetVol

jasoncollege24 wrote: ↑Sat Jun 29, 2019 5:07 pm Warrior, are you running P2R as admin in Windows 7?

Yes - Admin.

P2R is running on 3 of my machines.

1 x Laptop - I use P2R on this. It auto reboots daily - Never had a hang issue. Win 7 x64.
1 x Other Laptop - Hangs on it - 2 times now - Win 7 x 64 - P2R has not been run on this one for any commands however.
1 x Main Comp - Win 7 previously, now Win 10. P2R never hangs on it - No commands run on it ever though.

I spoke too soon! The crash where P2R uses as much CPU as it can get just happened on my file server now too. Aside from Comodo, and Windows 10, there's not a lot of similarities between these two machines, so as a test, I've added P2R's installation directory to my exclusions on my main computer (actually on both), but on the file server, i've not restarted P2R to ensure that system remains responsive, and available.

If that stops it, then the problem could have to do with antivirus in general. however... I doubt this will resolve it.

Some details I've accumulated about this crash

* Happens after P2R is running for a minimum of 48 hours (in all my cases)
* Opens hundreds (or more) of threads having to do with .NET 4.x
* Still accepts commands in said state (at least in my case)
* Not caused by Comodo Secure Shopping (still not sure about my other crash)
* Elevation seems to make no difference
* P2R update settings don't seem to effect it
* Increases P2R RAM usage in this state
* P2R eats up as much CPU as it can
* P2R Must be terminated to quit, and return CPU use to normal
* Happens on Windows 7, and 10
* Happens whether auto started, or manually
* Seemingly RARE (only one other known report in another post from 2018)
* Not caused by official P2R's garbage collection routines

Let me know if I missed anything

jasoncollege24 wrote: ↑Mon Jul 01, 2019 6:47 am * Happens after P2R is running for a minimum of 48 hours (in all my cases)
* Opens hundreds (or more) of threads having to do with .NET 4.x
* Still accepts commands in said state (at least in my case)
* Not caused by Comodo Secure Shopping (still not sure about my other crash)
* Elevation seems to make no difference
* P2R update settings don't seem to effect it
* Increases P2R RAM usage in this state
* P2R eats up as much CPU as it can
* P2R Must be terminated to quit, and return CPU use to normal
* Happens on Windows 7, and 10
* Happens whether auto started, or manually
* Seemingly RARE (only one other known report in another post from 2018)
* Not caused by official P2R's garbage collection routines

Yep - I agree with all the above - especially the 48 hour thing. Note I am not using any AV on my laptop.
I'm thinking it's a .Net thing of some sort. It happens so infrequently it's very hard to pinpoint what it could be.

Hey Rob,

would you like me to make another thread for the other high CPU crash, (the one where several items take up CPU, as opposed to just P2R?), or do you want to just keep that one on this thread as well?

I think you can just keep this one going - as far as I can see there have only been two people (including you) that have run into this problem; if others start to chime in that may be helpful in figuring out what is going on.

Also, breaking the thread into more under bugs would make it appear that there is a more widespread problem.

Regardless, I'll continue to do what I can to bottom it out - I just need more clues; from what I can see the garbage collection changes had nothing to do with it.

Thanks

Made an account to just let you know.. I also have the issue with 100% CPU after a longer time of not rebooting my win 10 PC. Don't have any logs, happened a few times, but only recently realized it and turned the program off to study this thread.

Poor Rob !

Where on earth do you start looking for something that takes 2 days to show a fault ?

Must be some .Net thing somewhere.

It's possible that Rob will simply release a new version in the future and fix the problem - and no one will really know what the cause of it was.

In the middle of this crash right now (I set affinity to 1 CPU so my system is responsive)

From what I can tell, this is *definitely* a .NET related issue. All the information below was gathered using Process Explorer, during the crash. (Process was restarted, and checked again for comparisons)

.NET CLR memory - # of sink blocks in use keeps climbing (Seen over 3k)
Throwing CLR exceptions every second (currently over 5k)
exception throwing begins the moment the app is launched (confirmed by watching ProcessExplorer during app start)
over 500 threads (peaked in the thousands, and seems normal right after restart, with only a handful of threads)
.net CLR Interop - # of CCWs is thousands (Also begins climbing a app start)
.net CLR security - Total runtime checks are in the millions


Hope this helps!

perhaps as a work around you could set task scheduler up to kill and restart the program at midnight (or something like that) every day. If after a couple of weeks the problems does reappear I can code something that would allow for a more graceful command line shutdown and restart.

Can manually do that, but if you want to go that route, you should probably also incorporate adding that task automatically during setup, if it's not already there, obviously letting the user know. You should also have it bypass UAC, and auto-run as admin this way.

If you do this, please let me know the name, and all relevant settings of the task, so I can change (or make) mine accordingly.

Obviously, the better route is to determine the cause of the problem, instead of using a band-aid method, so I'm likely to just continue trying to troubleshoot.

Did you want a list of running services? That's one thing we have not compared, and may be useful.