Shutdown issue...

Started by XP SP3 x86, May 09, 2012, 01:30:12 PM

Previous topic - Next topic

XP SP3 x86

After 5.1.0.66, with every single version I have a same issue. During shutdown/restart icon in task bar looks hilarious...



and usually I need to force close process lasso.exe, because popup appear on win desktop during shutdown "unable to close blah blah...". Last fine working version is 5.1.0.66.

Jeremy Collake

#1
Let me rewrite my response to this, as I've thought more about it.

There were some shutdown issues in 2K/XP that appeared due to changes in v5.1.0.68. However, these were resolved, and they were NOT as you describe here.

The RED traffic light icon is NORMAL. This simply means the core engine was shut down. In older builds, this 'feature' did not respond so quickly, and thus you likely didn't see it. If it is hilarious looking, perhaps I need to change the icon.

What I suspect in this case is that the change in shutdown ordering of the GUI and core engine resulted in a change in behavior. Simply waiting should cause Process Lasso to properly close. It may just be that your PC is taking a long time to shut down. In prior builds, perhpas this was mitigated by the different ordering in the shutdown procedure. Also, do check if there are message boxes or other that may be appearing in Process Lasso, preventing it from shutting down.

So, the changes to the code caused a change in the behavior of your PC shut down. This should not be critical though. A minor annoyance if anything. If you use any startup or shutdown optimization software, that software may exacerbate this condition. Similarly, if you 'aborted' or 'cancelled' a shutdown because you had open documents in an another application, that could exacerbate it.

This is something I continue to evaluate, and I appreciate the report. Due to the complications I had after backporting this change in behavior, I've been a lot more conservative, and thus have not issued a new minor update. However, perhaps this next one will 'get it' for you ... i just must make sure it doesn't 'break it' for others.

Do keep in mind that although I intend to try to address this, it is no huge deal ... and not uncommon for one or more applications to still need more time to shut down for some PCs. I always recommending waiting on them to properly close. It also certainly does not affect many people, though I know that's hard to hear when you're one it does affect.

If you have any startup or shutdown 'optimization' software, this may also impact Process Lasso.
Software Engineer. Bitsum LLC.

hanemach_gt

Have you tweaked some termination timeouts in registry (HungAppTimeout, WaitToKillAppTimeout, WaitToKillServiceTimeout)? I have, and for a brief period of time after invoking shutdown command PL's tray icon goes red, that's because I have all of the above registry values very low.
<img src="[url="http://imageshack.com/a/img913/7827/On37F9.gif"]http://imageshack.com/a/img913/7827/On37F9.gif[/url]"/>

Jeremy Collake

Those tweaks to the system would indeed change the behavior and likely resolve the issue, but I can not recommend them, as they are not technically 'safe', and I must be conservative in my recommendations. I am preparing a minor update to v5 and will attempt to change the behavior so that this does not occur for the OP. I've just got to make sure it gets done right. I've also got about 10 languages to check and make sure I haven't screwed up in the two branch confusion (v5 and v6).
Software Engineer. Bitsum LLC.

XP SP3 x86

QuoteHowever, these were resolved, and they were NOT as you describe here.

It's very simple answer, it's NOT resolved :)
I use everything by default in ENG xp, no registry edit, not changing settings in ProcessLasso, or whatever.
5.1.0.66 and all oldest versions, works like a charm, not a single issue. All other (newest) versions have a issue EXACTLY like I describe.
So, can't be "my" fault. It's something in latest versions developing.

Btw, tnx for the quick replys.

Jeremy Collake

#5
Nobody said it was your fault. I said the change in shutdown order caused a change in behavior of your PC. In recent versions, the shutdown ORDERING of the GUI and Core Engine were changed. This could cause an issue like you've seen on a small minority of systems that were already susceptible to 'slower than normal' shutdowns.

The issue I spoke of is different than yours, completely different. That's why I say *it* was resolved. I know it was resolved because I know the precise cause, fixed it, and verified the fix with multiple users affected by it. It wasn't an 'iffy' sort of fix either, it was a simple bug, a precise thing.

I know it SOUNDS similar, related to the shutdown, etc.. but it is totally different. PLEASE, let the programmer tell you if the issue is the same one or not.

NOWHERE did I say your problem did not exist, is your fault, etc... THUS, I am working on it. HOWEVER, I must first THINK .. as I don't want to arbitrarily adjust the shutdown behavior, then have someone else come to me and say I messed up their shutdown.

This is completely and totally different from the two issues that existed briefly:

Issue #1 - FIXED: The core engine would try to restart, causing a message box saying 'could not start governor because the window station is shutting down'. This didn't really hurt anything, but was an annoyance.
Issue #2 - FIXED: Shutdown of the ENTIRE 2K/XP PC was prevented while Process Lasso was running. No messages. No Forced closures. Just stopped in its tracks. Fixed within hours, as this was more serious. It was caused by an improper response to a message. Therefore, the cause was *known* and *resolved*, as verified in a thread here.
Issue #3: Your issue -- unlike either of the above.

My previous post sums it up, if read in its entirety. I am issuing a new minor update that further adjusts the behavior and will hopefully take care of you.

I do apologize. However, I have to determine exactly what is going on before I issue the fix. If some other XP user wants to chime in, please do. I don't see the issues in my test beds, but then they are perhaps a bit too clean, or too fast.
Software Engineer. Bitsum LLC.

edkiefer

I can confirm latest versions work fine shutting down on my system (XP SP3 MCE 2002 ) .

Only one version I had to shutdown 2 times to shut down system .
Bitsum QA Engineer

Jeremy Collake

Thanks Ed ... I was rewriting my post ten times, like I tend to do ;p. I am just going to go back to coding, and hopefully resolve the issue for this user.
Software Engineer. Bitsum LLC.

XP SP3 x86

I really appreciated your effort, tnx a lot.
Btw, this issue it's not big deal. I search the forum before I open this thread, and already readed all post with similar problem. I don't think I'm the only one with this "problem", maybe others are just to lazy to register/post on the forum. But, maybe I am :)
Anyway, I can stick with v.5.1.0.66. This version working like a charm.

Regards.

Jeremy Collake

I made adjustments for the next build, but can not guarantee their success. They change the shutdown ordering a bit. It is the only thing that changed, absent the unrelated governor recovery mechanism that caused issues. Consider it a test build. Please report back. Again, I am very sorry you experience this issue. Although there are lots of XP users on the forum, but you are probably right - if you see it, others surely do too.

BTW, are you running the core engine as a service or normal application?
Software Engineer. Bitsum LLC.

XP SP3 x86

Quote from: bitsum.support on May 10, 2012, 12:45:49 PM
BTW, are you running the core engine as a service or normal application?

I don't know what you talking about? :)
How to check that?

Jeremy Collake

If you don't know, then I know the answer ;). You have to intentionally set it to run as a service, something you'd definitely notice. Also, it will show the governor running in the 'system' context (another way to check).

No worries -- I have combed through the code, done some thought experiments, and *hope* this next build will fix your problems. Like I've expressed, I just want to make sure it doesn't cause problems for someone else, lol. Right now I am finishing 'fixing' the 10+ languages that got partially broken due to the v5/v6 branches, with the help of my translators. Well, not like they were unusable, its just that a handful of strings were 'lost'.

Anyway, release is coming very soon, and if it does *not* fix your issue, then please just report it to me, and we'll try some one-on-one experiments first next time.

Although this is a bit of a distraction from v6, but that's ok - it is something that also pertains to v6.

Thank you.
Software Engineer. Bitsum LLC.

Jeremy Collake

v5.1.0.80 is being built right now. It should be uploaded and released within 30 minutes.
Software Engineer. Bitsum LLC.

XP SP3 x86

I gonna inform you asap, is there any improvement (my case) in this version.

Thank so much for the effort.

DeadHead

In the meantime, since it's weekend and all, and since I very much like to 'speak the truth', here it comes - Process Lasso rules! ;D

And yes, that IS the truth! :)
Windows 10 Pro 64 (swedish) || Xeon 5650 @ +4 GHz || 24 gig ram || R9280 Toxic

Jeremy Collake

Thanks Deadhead ;). It will keep evolving for as long as I'm around. As you can imagine, when I'm contacted its more often when there's a problem of some sort for someone or another.
Software Engineer. Bitsum LLC.

Jeremy Collake

#16
Another user just reported via email that he too saw these issues with the prior build, but they are now gone. It seems the shutdown ordering adjustment was effective, at least for him.

As for that all red traffic light icon --- I believe I'll recreate that, though I'm clearly not much of an artist.
Software Engineer. Bitsum LLC.

edkiefer

No problem with v5.1.0.80 here with XP SP3 , just tested it an shuts down cleanly .
Bitsum QA Engineer

Jeremy Collake

Quote from: edkiefer on May 11, 2012, 08:11:01 PM
No problem with v5.1.0.80 here with XP SP3 , just tested it an shuts down cleanly .

Thanks ;). My tests have shown it is fine too. Now, back to work on NEW things ;). If I do not finish my work soon, a mob of people may come find me with pitchforks in hand, lol.
Software Engineer. Bitsum LLC.

TfH

One of my oldest test rigs (going to recycle it soon) is XP SP2, no probs at all on shutting down.

XP SP3 x86

Till now, v.5.1.0.80 works like a charm. Now previous issues, etc.

@Admin, tnx a lot for the effort & help :)

Keep up the good work & good luck!

Miroku4444

Well the latest fix(5.1.0.80) is now causing a start-up issue. Process Lasso is taking too long to boot up, and is preventing some of my other apps from starting. They all start up eventually, but a couple must wait for process lasso. One of them is my firewall, which might make me vulnerable while process lasso is starting up. 

Jeremy Collake

#22
Quote from: Miroku4444 on May 12, 2012, 11:05:58 AM
Well the latest fix(5.1.0.80) is now causing a start-up issue. Process Lasso is taking too long to boot up, and is preventing some of my other apps from starting. They all start up eventually, but a couple must wait for process lasso. One of them is my firewall, which might make me vulnerable while process lasso is starting up. 

That does not seem possible. I simply changed the order that Process Lasso shuts down, nothing at all related to start up. Nothing else. No change in startup procedure, order, or anything else really - except as listed in the change log (a few translated strings). I think this is more likely coincidental.

Maybe your security software had to re-scan it and add it to its cache, perhaps causing a one time penalty -- OR the security software was updated and had to rescan a bunch of applications. That's all I can think of. Process Lasso starts up near instantly if nothing else is going on. You know that.

Also, nothing waits on Process Lasso to start, unless you're using software that delays startup of applications so as to improve the bootup experience.
Software Engineer. Bitsum LLC.

Miroku4444

I fixed it, and it wasn't Process Lasso's Fault.  :) During a Microsoft update the service ".NET Runtime Optimization Service v2.0.50727_X86" got re-enabled. It uses a process called mscorsvw.exe. This sucker slows my start-up like crazy. I disabled it and re-booted. Now everything starts up like normal. I guess i forgot to disable it after a microsoft update.

Jeremy Collake

Quote from: Miroku4444 on May 12, 2012, 12:04:43 PM
I fixed it, and it wasn't Process Lasso's Fault.  :) During a Microsoft update the service ".NET Runtime Optimization Service v2.0.50727_X86" got re-enabled. It uses a process called mscorsvw.exe. This sucker slows my start-up like crazy. I disabled it and re-booted. Now everything starts up like normal. I guess i forgot to disable it after a microsoft update.

Thanks for the update ;). You had me worried, because such statements other people may take literally... as we all have slow to boot PCs ;). That 'optimization service' is actually trying to pre-optimize all your .NET apps by doing necessary .NET operations before those applications are opened. Its ironic it slows the boot time, though makes total sense. Perhaps we should make users aware of this service, as it seems to do more harm than good, at least in some cases.
Software Engineer. Bitsum LLC.

Miroku4444

Yeah, i'm glad it WASN'T Process Lasso.

This service also can slow boot time, and i have it disabled also. "Microsoft .NET Framework NGEN v4.0.30319_X86. "


Just like the other service, but this ones for .NET Framework 4 i guess?

Jeremy Collake

If you remember, when .NET was originally introduced it was so dog slow that Microsoft had to add all sorts of system services to help speed it up. Pre-load assemblies, pre-optimize, pre-compile MSIL to native code, etc..  All to hide just how slow and bloated .NET apps are. That particular service (the second one, NGEN), is described as: "NGen service allows the developer to defer the installation and update of native images to periods when the computer is idle." .. At least, that's how it is described by a person here: http://social.msdn.microsoft.com/Forums/eu/netfxsetup/thread/4dd266e6-a93b-4195-81f8-109312004f4f
Software Engineer. Bitsum LLC.

edkiefer

I noticed this too, lately MS has added a bunch of net related services . I don't want to get OT (maybe we could move/split this thread) . but here a few i noticed lately added (this is XP SP3 )

.NET Runtime Optimization Service v2.0.50727_X86

ASP.NET State Service

Microsoft .NET Framework NGEN v4.0.30319_X86

luckily only last is set to automatic by default  here.
Bitsum QA Engineer

Jeremy Collake

If any further discussion, we can move it to a new topic. I don't want to split it (I just checked for a good split point) because other people may see what Miroku4444 did, and I want it to be clear it's not Process Lasso, and his advice may help them.
Software Engineer. Bitsum LLC.

Miroku4444

QuoteAll to hide just how slow and bloated .NET apps are.

Most are, but Paint.NET is awesome and not bloated at all.

Jeremy Collake

Quote from: Miroku4444 on May 12, 2012, 02:02:59 PM
Most are, but Paint.NET is awesome and not bloated at all.

Agreed, Paint.NET is great ... HOWEVER, IIRC, it does do some pre-optimization during installation that allows it to load faster, as most .NET apps do, or *should* do. They optimize for the system as they are installed. Microsoft had to do lots of hacks to make .NET work fluidly, especially on older PCs. Of course, Paint.NET is perhaps one of the best examples of how things are when .NET is done *right*. A lot of .NET developers do things wrong, since .NET is easier to develop in and requires less expertise than native code.
Software Engineer. Bitsum LLC.

edkiefer

I was going to ask best way to tell if app uses .NET , but I found out easy way an figure share it here .

Process explore is color coded so if you load up a app it will show by default yellow is ,net apps . you can also tell by seeing dll loaded but that is pain to go through .

For me so far only my Canon EOS utility uses net . I don't have Paint.net as I use gimp for anything needed advanced PS work .
Bitsum QA Engineer

Jeremy Collake

#32
If you turn on the view of DLLs in Process Lasso, then you can also tell by the DLLs that are loaded .. but I will add an easy way to show this in the future if people want it. I do not want to waste resources being a full fledged task manager, but if enough people care, I'll show the info in a basic form.
Software Engineer. Bitsum LLC.

edkiefer

yes, that works too , though its not something you need to use everyday .
Bitsum QA Engineer

Hotrod

Quote from: bitsum.support on May 12, 2012, 07:59:57 PM
If you turn on the view of DLLs in Process Lasso, then you can also tell by the DLLs that are loaded ..

Huh??? Where do I find that?

edkiefer

Quote from: Hotrod on May 12, 2012, 08:39:47 PM
Huh??? Where do I find that?
first go to view > enable "show threads and modules"

then just highlight the app and hit the module tab in bottom window will show dll loaded .
Bitsum QA Engineer

Jeremy Collake

#36
Yea, note that its not that pretty. I actually also used to have a Handles tab.. again, I wanted to move AWAY from being a full task manager replacement, as I couldn't imagine trying to compete with the existing task managers. They do their job, and Process Lasso does a different job (automation and optimization). To try to add ALL task manager capabilities would bloat the product unnecessarily. If you take a look at Process Explorer, for instance, while active it consumes a fair amount of CPU resources to keep track of and display all that system status information.
Software Engineer. Bitsum LLC.

edkiefer

Quote from: bitsum.support on May 12, 2012, 12:44:24 PM
If you remember, when .NET was originally introduced it was so dog slow that Microsoft had to add all sorts of system services to help speed it up. Pre-load assemblies, pre-optimize, pre-compile MSIL to native code, etc..  All to hide just how slow and bloated .NET apps are. That particular service (the second one, NGEN), is described as: "NGen service allows the developer to defer the installation and update of native images to periods when the computer is idle." .. At least, that's how it is described by a person here: http://social.msdn.microsoft.com/Forums/eu/netfxsetup/thread/4dd266e6-a93b-4195-81f8-109312004f4f
This just happened to me , I updated net.ver4 and the service Microsoft .NET Framework NGEN v4.0.30319_X86. was set to auto and constant running running process .
Since I startup PL manually I found PL would take much longer time to load (like almost 1 min delay) other apps ran fine.
After few mins all is good but the net framework is still running .

It seems when you update/install Net it only adds files and then compiles on your end afterward , some parts are set to low priority it seems and only finish the compling when system is idle . This seems to be issue more in XP than later OS .

I found this link informative

http://social.msdn.microsoft.com/Forums/en/netfxsetup/thread/cb75c4dc-e0af-4b22-85b2-c2c1b08bfea1

It seems you can also force it to compile using CMD command line as noted in that link .

After today I notice the net process is dropped from running, so it does seem it needs some time, I updated yesterday . I'll see how it goes now on next reboot but this did look like something was wrong with PL , which is not the case .

So those that run into issue wait a few days or you could do as in link above and force compile , last resort would be set service to manual or disable but I think if you have any apps you will lose the optimization if service is not able to run .
Bitsum QA Engineer

Jeremy Collake

Good tip Ed, thanks!

You are exactly right in what the .NET Runtime (CLR) does to .NET code (MSIL). It pre-compiles it into native code for that particular system - so that the code runs faster when you use it. Other assemblies it just pre-optimizes by resolving dependencies and such. Of course, I"m no .NET expert, but know enough I guess ;p. Anyway, that's a great tip to force it to do this optimization right away!
Software Engineer. Bitsum LLC.

Miroku4444

QuoteSo those that run into issue wait a few days or you could do as in link above and force compile , last resort would be set service to manual or disable but I think if you have any apps you will lose the optimization if service is not able to run .

I always set it to disable. The only .Net thing i use is Paint.NET, and it runs fine with it disabled.

edkiefer

Just an update on my above post . no net running in backround or slowdowns now . SO I would give it few days with service on auto or as posted you can force the compile .

Yes, I guess you can put it to manual or disable if you only have few net app , only thing you lose any optimizations  (not sure what that means with net app)
Bitsum QA Engineer

KestutisS

Hi, to all...
  this may be a regression in 6.0.1.50 or a new issue -- on system Shutdown Process Lasso may try to start something as there are message boxes with failed initialization because of shutdown displayed:
   I tried to shutdown my PC several minutes ago, and the Icon in the tray was 3xRED (as it is described in the beginning of this thread), but the process did not terminate for about a minute. During that time I've got 4 message boxes with information that .DLL failed to initialize because system is going Shutdown (processgovernor.exe). (The text may be inexact).

   

edkiefer

Quote from: KestutisS on October 06, 2012, 10:29:16 AM
Hi, to all...
  this may be a regression in 6.0.1.50 or a new issue -- on system Shutdown Process Lasso may try to start something as there are message boxes with failed initialization because of shutdown displayed:
   I tried to shutdown my PC several minutes ago, and the Icon in the tray was 3xRED (as it is described in the beginning of this thread), but the process did not terminate for about a minute. During that time I've got 4 message boxes with information that .DLL failed to initialize because system is going Shutdown (processgovernor.exe). (The text may be inexact).


I get that to if I run Trillian (IM ) , it seems to have problems shutting down fast an clean . you may have a similar issue with some app .
Bitsum QA Engineer

edkiefer

For me when I see it I only get one message about a PL dll (I forget if its governor or PL.exe . My new system shutsdown fast , to be honest it maybe a sec or so delay.
I can hardly see what apears as dark large window saying Trillian and PL are delayed , I can't even read any popup on this win7 but get same thing on XP, and there its slower an easier to read message .

If I don't run Trillian then all is ok .

It does not cause any issue either , I can maybe check event viewer to see what it says if it made an event on it .
Bitsum QA Engineer

Jeremy Collake

Thanks for the extended information Ed. I think my previous postulations were wrong, especially after code analysis and the continued influence of Trillian as some external factor. I will see if i can set up a test bed to try to duplicate this, as I've never seen it - that's why I was guessing about the possible cause.
Software Engineer. Bitsum LLC.

edkiefer

yeh, if you try Traillian as test, make sure you populate (log on) to as many types as you can, this seems to make it do it. not sure if it has something to do with saving any logs or whatever but it happens almost 100% . this is also with me not even posting to anyone, just logged onto Astra (trillain's login), ICQ , skype and I sometimes IRC .

Edit: there a lot of issue with slow shutdown with Trillian it seems , here one link, I get same thing and PL gets added to list from what I remember . Mine doesn't take 20sec like the post but same symptom .

http://forums.ceruleanstudios.com/showthread.php?t=105919
Bitsum QA Engineer

KestutisS

Running ProcessLasso free 6.0.1.52 on Windows XP SP3:
   The first bug description was vague.
   During _long shutdown_  processlasso tries to start something. This is my diagnosis, as it shows Error, Ok only message box:
    caption :  "processgovernor.exe -- DLL Initialisation Failed"
    text     :  "The application failed to initialize because the Window station is shutting down." .
   The message box appears after the icon goes to fully red traffic light in the tray and some time passes. The one shown message box does not stop the process, and the longer you wait, the more of these you will get.

   Steps to reproduce:
     Start MS Excell (If You do not have one, think about a program, which will demand to save a document until you respond -- OpenOffice may do, or any other MS Office software, but I'm not sure, as I did not tested).
     write something into a new document and _DO NOT SAVE_
     From start menu, choose "Shutdown".
     Confirm the "Shutdown".
     Windows will try to shut down -- but before that they try to close all running applications. MS excel will ask to save the document -- do not. Wait -- You will see the message box i am writing about.
     Close the message box.
     Wait for two minutes -- you will see at least one more message box. Close one message box -- you will see there are more of it :)
     When You are done testing, you may save or not and let the system to go down.
   
   I did this test with as little running processes as I thought possible. As usually there are may things running (Skype, Dropbox, Office, several browses, Apache, MySQL... on this box, the shutdown takes a while, and I see the message boxes everytime I shut it down).   

   My thought is that processgovernor or whatever should not complain about shutdown. It should detect the "going down" state somehow and either quit or at least do not try to restart until the shutdown state is active. If shutdown is canceled, he may (re)start whatever it needs.
   Just one more a thought -- if I remember properly there is a feature in ProcessLasso to restart some process if it fails -- this feature, if it does not detect the "windows is going down" state, may cause something similar. I'm newbie with this software so please forgive me if I'm wrong.     

   Also, please forgive me that the first description was not exact and did not provide any steps to reproduce it.

Jeremy Collake

QuoteMy thought is that processgovernor or whatever should not complain about shutdown.

The complaint itself is not under the direct control of the governor, the system would generate that complaint any time any application is launched. Thus, the idea is making sure the governor is not launched.

Who launches it? The GUI, trying to 'recover' from what it errantly thinks is an error condition.

I suspect the involvement of other applications affects the shutdown speed of either PL or the system itself, exacerbating the situation.

I will evaluate this today. I am sure I designed the system to not try to re-launch the governor if the window station was shutting down, but apparently something is askew. This 'self-recovery' mechanism, which is not needed anyway, causes this behavior. Thus, it will be neutered and/or fixed immediately.

A new final will come soon and fix this. By the end of the week for sure, possibly sooner.
Software Engineer. Bitsum LLC.

Jeremy Collake

#48
I adjusted the timing so that the thread that watches over the governor should hopefully not interrupt in the future. We'll see though, I am considering refactoring it a bit.

The primary issue turns out to be this:

1. The governor is told the system is shutting down, and so shuts down.
2. 20 other apps are told, and start shutting down.
3. The GUI is told, and finally begins its shut down.

Thus, the GUI doesn't realize the system is shutting down, and tries to re-launch the governor. Giving more time for #2 to take action, and/or checking the system state is the appropriate fix. I've tried the former for now, as a quick band-aid.
Software Engineer. Bitsum LLC.