Process Lasso management console keeps reappearing..

Screemer · April 19, 2011, 03:37:54 AM

Hello,

I am a long time paying customer..

I was trying out the latest beta v4.09.39 beta x64, have tried some earlier versions to before but can't really remember what version.

I seem to have a problem on one of my machines Windows 7 Ultimate x64, the management console window keeps reappearing about every minute or so.
I really like what it does for my system but I really can't have the console breaking my full-screen gaming all the time.

I have the same version running on another Windows 7 Professional x64 machine and it seem to be working just fine.

I have upgraded from a stable release on both machines and I don't have any special settings other than High Performance + MW and boost foreground processes on either machine.

Do you have any idea what could be causing this? Or is there any way I can find what makes the console reappearing all the time?

Ps, Keep up the truly amazing work, your software really ROCKS.

Jeremy Collake · April 20, 2011, 01:37:57 AM

That is weird... let me look into this immediately. I hope I didn't post an internal build by accident (I am working on a periodic self-restart).

Jeremy Collake · April 20, 2011, 01:42:25 AM

My GOD! THANK YOU FOR LETTING ME KNOW!!!

Somehow an internal build got posted. I don't know when this happened to be honest, nor if it applies to all builds or just the workstation x64 build. I am issuing an immediate fix. Oh my goodness... I can not believe I somehow made that mistake. It had to be an accidental upload of some sort.

Jeremy Collake · April 20, 2011, 01:51:29 AM

A corrected build has been issued. Thank you again for making me aware of this. I believe ONLY the workstation x64 build was affected, because that is usually all I build for internal builds (as that's what I'm running). So, the other builds were their same old self, but the workstation x64 build had internal beta code that was never intended to go out to the public.

Screemer · April 20, 2011, 02:46:58 AM

Smile, shit happens..

Well I installed the non beta version on-top of the beta and it still pops up regularly..

Is there any way to make it stop or do I have to re-install meaning totally uninstall the old version and then install the latest? What makes it reappearing, is it in the conf or is it in the code? what I mean is, can I save my config and re-apply it after a re-install?

Thanks for a truly great peace of software..

Jeremy Collake · April 20, 2011, 04:10:48 AM

Thanks much for the support, I really do appreciate it. As with all supporters, I encourage you to rate us (good or bad) at whichever rating site you use (if any).

There are two possibilities:

I jumped the gun and assumed the problem was the experimental feature and it is in-fact something strange not seen before (unlikely)
Somehow the old beta is still installed despite install of the stable. I do not know how this could occur, as it is designed not to (just tested now). Check the version number in the about box. Try downloading again, perhaps with a different browser if one is installed.

I *hope* that helps, and we can get to the bottom of this

Screemer · April 20, 2011, 04:59:45 AM

Sure I pay for great software, even though I know it's quite easy to find Process Lasso and other Bitsum software hacked and cracked on different sites if you search for it.. That seem quite unfair since I know how much time it takes to develop really good software..
Click the image to get a bigger version
This is how it looks right now.

The strange thing is that I am running the beta (same download copied to the home box) here at work and that installation is not reappearing..

Perhaps I should try to re-download the beta and do a total uninstall of Process Lasso and then do a clean install to see if that helps..

I just now tried to upgrade the one I have at home to v4.09.41, still same problem, periodically it puts the management console window on my screen.. Perhaps a un-install and new install is the only way to fix it?

Ps, I now advertize for Process Lasso on my website.

http://www.micke.screemer.nu (hope you like it)..

edkiefer · April 20, 2011, 10:54:02 AM

Jeremy

I think it affected 32bit to as I noticed on last few beta the auto game mode was being enabled when I played games (I started to see in log game mode for games setup, same in try (game mode checked)) .Ones I setup before timelimit expired so I assume 4.09.39 was affected too at least .

Edit: To be clear I still got window pop up and could not use advanced options as should be but seems what was setup was working , at least the auto-game mode, not sure on rest as I only have default settings .

Edit2: nevermind I think this is something else .

Screemer · April 20, 2011, 04:11:27 PM

Did a uninstall, reboot, install in other directory and didn't save settings from old version and now it works.
Added a game to the Configure Game Processes and still working.

In this version I also noticed a new feature I haven't seen before..
Self re-start Process Lasso every

Disabled all restarts, dunno if that's been there before?

At least now it's working as I want.

Thanks for all the help.

petrossa · April 23, 2011, 05:17:41 AM

I can dig the restart every x days. If you go to S3 state i noticed myself that if you write around WM_POWERBROADCAST you need to be very careful since these messages can't be relied upon to arrive on time. I've one app i need to close on S3 and restart because otherwise it'll fail most of the times.

Jeremy Collake · April 23, 2011, 12:08:18 PM

The self-restart isn't active yet. It is a last-ditch safety mechanism I put in for use in betas mostly, in case there ever is a memory leak or other reason why you'd need to restart the GUI every so often. There hasn't been a memory leak or any problem with the core engine in forever, but the GUI is more susceptible to such things (especially in beta). So, that's its purpose, although it is non-functional for the moment (as it should tell you when you click any of the options there now).

More versions are coming quickly.

petrossa · April 23, 2011, 02:45:01 PM

I've noticed changes to the preemptive taskmanager's algorythm. (i think, i have no access to it's code obviously)
It shows most in the timer. Before an apps timer was given equal slices, but since some time (can't really say which build of win7) it seems like the timeslices are more staggered for standard apps under heavy load. Such as S3 wakeup.

A timer may leap from let's 10 msces to 20 msces and then counts normally and leaps again a bit. The net result is that your timer is off from realtime more then before. I believe. It's the only way i can explain issues i have with old code behaving differently from S3 wakeup in multi-threaded programs.

Doesn't show up in normal startup, since evidently no threads were already on a timer stack.

All a bit vague i know. But i have in my programs now a similar restart automatically setup and that works better then just pausing on a power broadcast. that's why i commented on the issue believing you had stumbled on the same.....

Jeremy Collake · April 23, 2011, 02:48:12 PM

@petrossa: I do not currently monitor power change events so it is not likely related. I have stuck my foot in my mouth too many times, so I am going to stick to coding and getting this stuff all fixed up

.

Jeremy Collake · April 23, 2011, 08:48:35 PM

@petrossa: You are actually on to something unrelated with your question of timers. One thing you may wish to consider is the frequency scaling implemented on all modern CPUs and the default power scheme of Windows. That may have an impact, though I don't know for sure. You are really on something unrelated. OR I have misunderstood what you are trying to tell me. If I am too dense, please drill it into my head

My self-restart is actually rather stupid and simple, doesn't do anything smart at all. It creates a thread and waits X until the restart time occurs, so it isn't even accurate (nor does it need to be). It is a safety likely never to be used except in beta development, as I sure am not going to publish a final with a memory leak.. even if it takes months to build to 1MB

.

For current power scheme resolution it was determined the code is so quick that it is faster and better to just keep an eye on it along with the processes rather than try to register events that may or may not be reliable. Of course, system events are used in other cases.

petrossa · April 24, 2011, 01:42:51 PM

I'll try and not get you too distracted. I was talking about timer resolution and threads that use a waitfor can get thrown off course. Let it slide, no matter. Btw today 4 reboots, 3 crashes

Jeremy Collake · April 24, 2011, 02:24:08 PM

Quote from: petrossa on April 24, 2011, 01:42:51 PM
I'll try and not get you too distracted. I was talking about timer resolution and threads that use a waitfor can get thrown off course. Let it slide, no matter. Btw today 4 reboots, 3 crashes

Hmm, I had not heard of that occurring. I will look into it. I did not realize that was what you were referring to. That seems like an extreme violation of the very principles of the synchronization objects ;o. I will research it. If you have any links that describe the scenario you speak of, let me know.

Sorry to hear the crashes continue. At least I know where it ISN'T now. I have now become convinced it is in the inter-process communication, and am going through it now. I am also thinking there were two race condition type crashes, one of them fixed -- as I can't duplicate it on my test bed when I previously could.

Jeremy Collake · April 24, 2011, 03:17:33 PM

Quote from: petrossa on April 23, 2011, 02:45:01 PM
I've noticed changes to the preemptive taskmanager's algorythm. (i think, i have no access to it's code obviously)
It shows most in the timer. Before an apps timer was given equal slices, but since some time (can't really say which build of win7) it seems like the timeslices are more staggered for standard apps under heavy load. Such as S3 wakeup.

The staggering you see in Windows 7 is due to the scheduler giving each thread a time slice of X CPU cycles, instead of X time length. This was the change, but I believe it was made in Vista (iirc). The system timer should not be affected under any circumstances really. The CPU frequency can scale around, but it shouldn't matter.. in theory.

Of course, you may be speaking of NEWER changes of some type, I am not sure.

Like I updated, please do send any research you have on this strange report of waitable objects not behaving like they theoretically should.

Jeremy Collake · April 24, 2011, 03:36:07 PM

I am releasing a new beta in a few minutes that makes an experimental change to the inter-process communication. The governor's 'sender thread' now waits 5 seconds before it transfers anything. I *believe* there is a theoretical condition where if events are sent too early during the initialization of the GUI then they can cause a subsequent crash. I am inserting other safety catches as well, but they are not in here yet. I'm mostly curious if this affects the crash.

In addition, I'm evaluating the constructors of the couple global objects.

Soon every component of the startup will have been checked ;o.

I need to do some proper debugging of this too. As I said, I gotta spend more time coding, less talking, lol

. Besides, I talk too much already ;p

Jeremy Collake · April 24, 2011, 06:09:35 PM

Also, anyone still seeing this crash may want to try NOT starting the core engine explicitly. The GUI will do an auto-launch of the governor, so it will end up running. This would be an interesting experiment and likely to have an impact, even if that impact is simply to change things up enough to work around the condition ;o.

petrossa · April 25, 2011, 02:48:55 AM

Quote from: jeremy.collake on April 24, 2011, 03:36:07 PM
I am releasing a new beta in a few minutes that makes an experimental change to the inter-process communication. The governor's 'sender thread' now waits 5 seconds before it transfers anything. I *believe* there is a theoretical condition where if events are sent too early during the initialization of the GUI then they can cause a subsequent crash. I am inserting other safety catches as well, but they are not in here yet. I'm mostly curious if this affects the crash.

In addition, I'm evaluating the constructors of the couple global objects.

Soon every component of the startup will have been checked ;o.

I need to do some proper debugging of this too. As I said, I gotta spend more time coding, less talking, lol . Besides, I talk too much already ;p

That is what is was referring to, the 'wait 5 seconds'. By trial and error (and lot's of aspirine) i came across the problem that 5 seconds only last 5 seconds in 'virtual time'. In realtime it can be 4 or 6. Whilst on that scale a second more or less doesn't really matter on smaller scales the timer issue gets to be an unpredictable quantity.

In the same circumstances one reboot modules load in different orders depending on the inevitable race condition in the OS itself. Since system process have always priority over any other time slices aren't distributed equally over all processes going on.

Which results in some processes running out of sync. I find it hard to create a reproducible codesegment, since by it's very nature the issue is random.

All i can say is be just observing the random behavior of multi-threaded programs i wrote that without essential changes suddenly become weird after some build of Win7. Evidently i can't pinpoint the exact build since the issue was so random it didn't occur to me till recently, and also due to your problems.

It connects on some level, your issues and mine. Whilst i only have problems with programs i wrote for my personal homeautomation system i can just kludge it, i wish you all the luck in the world getting this right.

My take: Don't get to caught up in finding the error in your code, but spend your energy to find a workaround.