Windows crash on suspend/hibernate with TCMD active

[Juanma Barranquero]

Windows 7 Home Premium 64-bit, TCMD 11x64.

I've been using Windows 7 for about three months, and in that time I've had quite a few Windows crashes on hibernate or, less often, on suspend. The thing all have in common is that TCMD was running at the time of the suspend/hibernate. If TCMD is not running, the crash never happens.

That does not mean that every suspend/hibernate with TCMD running crashes Windows; I'm not sure, and I don't like the idea of purposefully crashing Windows to test it.

 

[rconn]

> Windows 7 Home Premium 64-bit, TCMD 11x64.
>
> I've been using Windows 7 for about three months, and in that time I've
> had quite a few Windows crashes on hibernate or, less often, on
> suspend. The thing all have in common is that TCMD was running at the
> time of the suspend/hibernate. If TCMD is not running, the crash never
> happens.
>
> That does not mean that every suspend/hibernate with TCMD running
> crashes Windows; I'm not sure, and I don't like the idea of
> purposefully crashing Windows to test it.

There's no way that TCMD could be responsible for that. (Unless Microsoft
has reverted to MS-DOS and somehow removed all distinctions between kernel
and user mode!)

TCMD has no kernel mode components, and is thus incapable of causing a
Windows crash.

Rex Conn
JP Software

 

[Juanma Barranquero]

TCMD has no kernel mode components, and is thus incapable of causing a Windows crash.

I cannot know whether TCMD is triggering a Windows bug; likely. But what I've reported is my direct experience. Perhaps you can figure it out and work around it, as you've done for many other Windows bugs.

 

[rconn]

> ---Quote (Originally by rconn)---
> TCMD has no kernel mode components, and is thus incapable of causing a
> Windows crash.
> ---End Quote---
> I cannot know whether TCMD is triggering a Windows bug; likely. But
> what I've reported is my direct experience. Perhaps you can figure it
> out and work around it, as you've done for many other Windows bugs.

I wouldn't get your hopes up. Both the hardware and Windows make it
impossible for TCMD to be doing this or even involved in any way. If there
were a catastrophic Windows 7 & Intel hardware bug that allowed a user-mode
app to crash the kernel, it's unlikely that no other TCMD users would have
reported it.

You'd be better off spending your time looking for the real culprit, which
is most likely a device driver (probably your video driver; that's what
causes most crashes when waking from hibernation).

Rex Conn
JP Software

 

[Juanma Barranquero]

Both the hardware and Windows make it
impossible for TCMD to be doing this or even involved in any way. If there
were a catastrophic Windows 7 & Intel hardware bug that allowed a user-mode
app to crash the kernel, it's unlikely that no other TCMD users would have
reported it.

There's no need for a hardware bug. Even if what crashes is a driver (I suppose so, yes), some user-mode code could be calling a system-level API in an unusual (but correct) way that invokes a low used code path. There's a difference between saying "the user code cannot bring the system down" and "the user code cannot ask for something reasonable and just trigger a bug in system-land".

You'd be better off spending your time looking for the real culprit, which is most likely a device driver (probably your video driver; that's what causes most crashes when waking from hibernation).

Well, my crash is on suspending, not waking. And there's the inescapable fact that it only seems to happen when TCMD is running.

 

[rconn]

> Well, my crash is on suspending, not waking. And there's the
> inescapable fact that it only seems to happen when TCMD is running.

But you have to contrast your "seems to happen" with the inescapable fact
that it's absolutely impossible (both hardware + OS) for TCMD to be
involved, and the fact that you're apparently the only one suffering the
problem. You should be looking at your system configuration & device
drivers, and any apps you're running that have kernel-mode components (like
antivirus apps or screen managers).

Google shows a couple hundred thousand matches for Windows 7 crashes when
sleeping or hibernating (none of them mentioning TCMD).

Rex Conn
JP Software

 

[Juanma Barranquero]

the inescapable fact
that it's absolutely impossible (both hardware + OS) for TCMD to be
involved

No, sorry, it's not absolutely impossible.

 

[thedave]

On Fri, 01 Jan 2010 04:59:39 -0600, Juanma Barranquero
<> was claimed to have wrote:

>---Quote (Originally by rconn)---
>the inescapable fact
>that it's absolutely impossible (both hardware + OS) for TCMD to be
>involved
>---End Quote---
>No, sorry, it's not absolutely impossible.

With all due respect, it is impossible for TCMD to be the cause of the
crash. Bluescreens and similar can only happen due to bad or buggy
hardware or kernel mode processes.

Although a user mode process might be involved, the bug is always in the
kernel or code running in kernel mode, the kernel simply isn't allowed
to allow a user mode process to interfere at the system level.

Display drivers are responsible for some huge percentage of bluescreens
so they're always a good place to start looking. It's possible that
your display driver crashes due to the way TCMD creates toolbars, or due
to some attribute set on the window class or similar, but ultimately,
that's a buggy driver and must be addressed there.

Address the underlying crash and the problem will go away, anything else
is a Band-Aid.

 

[Juanma Barranquero]

With all due respect, it is impossible for TCMD to be the cause of the crash. Bluescreens and similar can only happen due to bad or buggy hardware or kernel mode processes.

Although a user mode process might be involved, the bug is always in the
kernel or code running in kernel mode, the kernel simply isn't allowed
to allow a user mode process to interfere at the system level.

With all due respect, that's why I wrote that it is not impossible at all for TCMD to be involved; I said nothing about it being the cause, on the contrary, I said that I think it is just triggering the bug.

It's possible that your display driver crashes due to the way TCMD creates toolbars, or due to some attribute set on the window class or similar, but ultimately, that's a buggy driver and must be addressed there.

I'm glad we agree.

 

[Joe Caverly]

Windows 7 Home Premium 64-bit, TCMD 11x64.

I've been using Windows 7 for about three months, and in that time I've had quite a few Windows crashes on hibernate or, less often, on suspend. The thing all have in common is that TCMD was running at the time of the suspend/hibernate. If TCMD is not running, the crash never happens.

That does not mean that every suspend/hibernate with TCMD running crashes Windows; I'm not sure, and I don't like the idea of purposefully crashing Windows to test it.

Hi,
While I use XP, you may want to create a batch file using the ON RESUME and ON SUSPEND commands in a detached batch file to see what is going on. You could use TASKLIST.EXE to capture what is running when the system goes to sleep or hibernates, and when the system resumes from sleep or hibernate.

Normally you would use the internal TASKLIST provided by TCC, but if I remember correctly from another post, Rex said that the /L option does not work in 64-bit Vista and above. As I do not have Vista or above, not sure if TASKLIST.EXE is still available in those OSes.

TASKLIST.EXE /SVC will provide you with a list of what processes are running.

I had a problem similar to yours, and it turned out to be one of the processes for my HP Printer. I upgraded the printer drivers, and have not had the problem since then.

Joe

 

[Juanma Barranquero]

you may want to create a batch file using the ON RESUME and ON SUSPEND commands in a detached batch file to see what is going on. You could use TASKLIST.EXE to capture what is running when the system goes to sleep or hibernates, and when the system resumes from sleep or hibernate.

I'll do that, thanks for the suggestion.

if I remember correctly from another post, Rex said that the /L option does not work in 64-bit Vista and above.

I also remember him saying that, but "tasklist /L" seems to work as expected on 64-bit Windows 7.