Stubborn Programs on Shutdown

When shutting down Windows 7, ASUS's VIA HD Audiodeck seems to resist, and I get the "Force Shutdown?" dialog from the OS.

If I press cancel, the audiodeck immediately shuts down.

Is it possible the OS is interrupting the otherwise graceful shutdown of this application, entering into some sort of privileges related deadlock?

(Someone who just glances at this might say "this is an app issue, not an OS issue," but I think that misses the context here. This is a question about how 7 halts operations on shutdown and during shutdown related dialogs, and it might also deal with how privileges are handled during system wait() operations, key OS issues.)

I'm curious how long you have waited for it to shutdown without your help. While there is no doubt in my mind that this ASUS program should shutdown instantly, I've seen a few programs that take a few seconds from time to time.

Bye.

Check for a updates on Asus web site.

Most often, this is an app issue, contrary to what you posted. When the OS issues shutdown commands, some misbehaving apps don't cooperate. The easiest way to know for sure is to manually kill off the Asus app, including services and running .exes. Wait a minute or so, and then do a normal shutdown. If the system shutsdown quickly, you know that it is definitely the Asus app's fault.

This is Deadlock

Deacon's experiment analyzes whether or not, in the absence of the app, the OS experiences this problem on shut down. It does not. That is entirely beside the point.

What I have evidence of is not just some odd behavior resulting from a program, but evidence of deadlock, a condition where two processes wait idly on resources (maybe just a "go" bit) from each other preventing any change of state. Whenever I cancel the shutdown, the AudioDeck closes instantly. If I force closed the audio deck, shutdown completes gracefully. Each process is waiting on the other.

Deadlock is an OS issue

Applications and the OS have well defined roles. We keep them to these roles so that we don't invite problems related to privilege escalation. One role reserved for the OS is dealing with privileges and doling out resources to the other processes. Solving deadlock is one function of a well written OS. Making applications handle deadlock situations leads to enormous security issues and would create a radically unstable OS.

This is why I feel that even if this problem is caused by no other app in the world, it would still be an OS issue

You can find further discussions of deadlock and starvation in any good textbook on Operating Systems, I've linked to Tanenbaum and Silberschatz below. You might also want to check out the dining philosophers problem on wikipedia.

Amazon.com: Operating System Concepts (Windows Xp Update) (9780471250609): Abraham Silberschatz, Greg Gagne, Peter Baer Galvin: Books
Amazon.com: Modern Operating Systems (2nd Edition) (GOAL Series) (9780130313584): Andrew S. Tanenbaum: Books

brownbat said:

If I force closed the audio deck, shutdown completes gracefully.

Call it what you want, but that's the issue. Besides, in your given explantion, you contradict yourself. If both apps are waiting for each other, how can the problem be solved by removing the offender?

This is a classic issue of a misbehaving app. There have even been apps created to resolve this. What you need is an updated driver/software package that fixes the issue. Nothing more, nothing less. I know it is cool to point the finger at Microsoft and their OS, but your comments confirm the culprit.

DeaconFrost said:

brownbat said:

If I force closed the audio deck, shutdown completes gracefully.

Call it what you want, but that's the issue. Besides, in your given explantion, you contradict yourself. If both apps are waiting for each other, how can the problem be solved by removing the offender?

This is a classic issue of a misbehaving app. There have even been apps created to resolve this. What you need is an updated driver/software package that fixes the issue. Nothing more, nothing less. I know it is cool to point the finger at Microsoft and their OS, but your comments confirm the culprit.

True dat. I have the same/app driver on the HTPC. Upgraded app/driver solved the same problem.

brownbat said:

When shutting down Windows 7, ASUS's VIA HD Audiodeck seems to resist, and I get the "Force Shutdown?" dialog from the OS.

If I press cancel, the audiodeck immediately shuts down.

Is it possible the OS is interrupting the otherwise graceful shutdown of this application, entering into some sort of privileges related deadlock?

(Someone who just glances at this might say "this is an app issue, not an OS issue," but I think that misses the context here. This is a question about how 7 halts operations on shutdown and during shutdown related dialogs, and it might also deal with how privileges are handled during system wait() operations, key OS issues.)

No, it is far more likely the ASUS Audiodeck is interrupting the graceful shutdown of the OS... The tell is that if you manually close the app first the OS shuts down as you expect.

This is not a deadlock... it is most likely just a glitch in the audiodeck. Either uninstall it or shut it down manually before shutting down Windows.

Thank you for the suggestions. My drivers are up to date, but I reinstalled them anyway. No change. Uninstalling the app kills key functionality for me.

DeaconFrost sees a contradiction in how two apps waiting on a resource could proceed when one is shutdown. CommonTater believes the "tell" that this is not deadlock is that shutting down the app early allows the OS to quit gracefully.

This is helpful, because it shows that I wasn't very clear earlier. In a deadlock situation, two processes are waiting for the other to finish. Killing either will allow the other to continue. I'm sorry, I was referring to this terminology assuming everyone knew what I was referring to, but I should have spelled this out the first time. Some people took a course in OS a long time ago, and might not remember all the keywords used in that context.

So Deacon, that's how shutting down one allows the other to finish, because they are waiting, not on some result from the other, but simply for each other to be done. Tater, this is why the "tell" you describe to me suggests deadlock. If you have a system stuck in wait, but you can avoid that wait by shutting down an app OR by canceling the shutdown process, then it seems like a clear tell of a deadlock scenario. Shutting down the app early means that the OS shutdown procedure is never waiting on it to exit, because it's already exited. Does that make more sense?

I understand now that this isn't really a forum where I can connect with developers to discuss what theory they were using for their approach here, so I'll just use the workaround of shutting down twice, it's not so difficult.

Thanks for your time though.

You might find the following articles helpful or interesting:
On priority inversion: Priority inversion - Wikipedia, the free encyclopedia
On semaphores: Semaphore (programming) - Wikipedia, the free encyclopedia
On deadlock: Deadlock - Wikipedia, the free encyclopedia
And this one on another resource problem that you might find interesting: Dining philosophers problem - Wikipedia, the free encyclopedia

brownbat said:

This is helpful, because it shows that I wasn't very clear earlier. In a deadlock situation, two processes are waiting for the other to finish.

That's correct. Interprocess signalling results in a situation where process A is waiting for process B at the same time as B is waiting for A.

Killing either will allow the other to continue.

Nope... killing the OS will not allow the ASUS tool to continue.


But what you encountered is NOT a deadlock... The OS is indeed waiting for the ASUS thing to close down... However the ASUS tool is not waiting for the OS to close down. There is no deadlock... It's more like a roadblock where the ASUS tool is standing in the OS's way. Most likely the ASUS tool has a message handling glitch and isn't reacting to the WM_POWERBROADCAST message in a timely manner.

Tater, this is why the "tell" you describe to me suggests deadlock. If you have a system stuck in wait, but you can avoid that wait by shutting down an app OR by canceling the shutdown process, then it seems like a clear tell of a deadlock scenario. Shutting down the app early means that the OS shutdown procedure is never waiting on it to exit, because it's already exited. Does that make more sense?

I'm going to go out on a limb here and guess that you've never actually written Windows code at any level beneath Object Abstraction... perhaps Delphi or C# for .NET? Things are a little different at the API interface level, and below.

For one thing... there is no "stuck in wait" in Windows. It's sequential multitasking, global OS wait states died with MS-DOS.