DUN Will Not Allow Standby

[Christopher Luther]

Hello,

We've run into an interesting scenario whereby any portable computer that is
on battery cannot automagically enter the system standby (i.e., suspend)
state if there is an active DUN connection. It doesn't matter if this
computer is running Windows 2000 Pro, Windows XP Pro, or Windows XP
Embedded -- if there is an active DUN connection, standby will not happen.

If this functionality documented any where? Or is this an anomaly with DUN?

And to answer your question "why would anyone want their computer to enter
standby with an active DUN connection?" The answer is that we have a
solution whereby a background process (when awake) polls a remote system and
sends/receives any waiting "messages". The people who this solution are
used to placing their portable computer down for 30 min. or so, having the
system enter standby, and upon re-awakening, start polling again.

Oh, and original sulution was Windows CE based but now there is a move to
standardize on Windows XP; hence the "new" issue with DUN.

TIA!

 

[Richard G. Harper]

I don't know if it's documented but I would strongly suspect it is indeed
engineered behaviour. Why would you want to put a system into standby mode
if a DUN connection is present?

--
Richard G. Harper [MVP Shell/User] (e-mail address removed)
* PLEASE post all messages and replies in the newsgroups
* for the benefit of all. Private mail is usually not replied to.
* My website, such as it is ... http://rgharper.mvps.org/
* HELP us help YOU ... http://www.dts-l.org/goodpost.htm

 

[Christopher Luther]

Hi, Richard.

To answer your question (as explained in my original post):

"The answer is that we have a solution whereby a background process (when
awake) polls a remote system and sends/receives any waiting 'messages'. The
people who this solution are used to placing their portable computer down
for 30 min. or so, having the system enter standby, and upon re-awakening,
start polling again."

The solution, as architected, uses an intelligent background process to
initiate a DUN connection for the message polling. This process will, if
one were to manually place the portable computer into Standby mode (i.e.,
Start menu, Shutdown, Stand by option), suspend its polling and, when the
computer next awakes, will automatically re-initiate a DUN connection and
resume polling.

Make sense?

The problem is not in a manually initiated Standby but in the fact that an
active DUN connection will not allow the System Idle timer to automagically
place a computer into Standby. And as I stated previously, it appears to be
*any* DUN connection - Windows 2000 Pro, XP Pro, and XP embedded - all using
different modems.

So you say, "Why not train the user to manually put their computers into
standby before setting them down? Surely it's a training issue." Well yes
and no. The ultimate end-users are "old timers" who would rather throw
computers out the window than actually use them properly and seem to want to
find ways for things to fail. And as I'd also stated previously, the
original CE-based solution didn't suffer from this anomaly; so it's become a
failure point with which to beat us.


- Christopher

I don't know if it's documented but I would strongly suspect it is indeed
engineered behaviour. Why would you want to put a system into standby mode
if a DUN connection is present?

--
Richard G. Harper [MVP Shell/User] (e-mail address removed)
* PLEASE post all messages and replies in the newsgroups
* for the benefit of all. Private mail is usually not replied to.
* My website, such as it is ... http://rgharper.mvps.org/
* HELP us help YOU ... http://www.dts-l.org/goodpost.htm

Hello,

We've run into an interesting scenario whereby any portable computer that
is on battery cannot automagically enter the system standby (i.e.,
suspend) state if there is an active DUN connection. It doesn't matter
if this computer is running Windows 2000 Pro, Windows XP Pro, or Windows
XP Embedded -- if there is an active DUN connection, standby will not
happen.

If this functionality documented any where? Or is this an anomaly with
DUN?

And to answer your question "why would anyone want their computer to
enter standby with an active DUN connection?" The answer is that we have
a solution whereby a background process (when awake) polls a remote
system and sends/receives any waiting "messages". The people who this
solution are used to placing their portable computer down for 30 min. or
so, having the system enter standby, and upon re-awakening, start polling
again.

Oh, and original sulution was Windows CE based but now there is a move to
standardize on Windows XP; hence the "new" issue with DUN.

 

[Richard G. Harper]

Sorry, but I see this as the exception to the rule, not the rule itself. I
don't think it's anything you can alter in any case.

--
Richard G. Harper [MVP Shell/User] (e-mail address removed)
* PLEASE post all messages and replies in the newsgroups
* for the benefit of all. Private mail is usually not replied to.
* My website, such as it is ... http://rgharper.mvps.org/
* HELP us help YOU ... http://www.dts-l.org/goodpost.htm

Hi, Richard.

To answer your question (as explained in my original post):

"The answer is that we have a solution whereby a background process (when
awake) polls a remote system and sends/receives any waiting 'messages'.
The people who this solution are used to placing their portable computer
down for 30 min. or so, having the system enter standby, and upon
re-awakening, start polling again."

The solution, as architected, uses an intelligent background process to
initiate a DUN connection for the message polling. This process will, if
one were to manually place the portable computer into Standby mode (i.e.,
Start menu, Shutdown, Stand by option), suspend its polling and, when the
computer next awakes, will automatically re-initiate a DUN connection and
resume polling.

Make sense?

The problem is not in a manually initiated Standby but in the fact that an
active DUN connection will not allow the System Idle timer to
automagically place a computer into Standby. And as I stated previously,
it appears to be *any* DUN connection - Windows 2000 Pro, XP Pro, and XP
embedded - all using different modems.

So you say, "Why not train the user to manually put their computers into
standby before setting them down? Surely it's a training issue." Well
yes and no. The ultimate end-users are "old timers" who would rather
throw computers out the window than actually use them properly and seem to
want to find ways for things to fail. And as I'd also stated previously,
the original CE-based solution didn't suffer from this anomaly; so it's
become a failure point with which to beat us.


- Christopher

I don't know if it's documented but I would strongly suspect it is indeed
engineered behaviour. Why would you want to put a system into standby
mode if a DUN connection is present?

--
Richard G. Harper [MVP Shell/User] (e-mail address removed)
* PLEASE post all messages and replies in the newsgroups
* for the benefit of all. Private mail is usually not replied to.
* My website, such as it is ... http://rgharper.mvps.org/
* HELP us help YOU ... http://www.dts-l.org/goodpost.htm

Hello,

We've run into an interesting scenario whereby any portable computer
that is on battery cannot automagically enter the system standby (i.e.,
suspend) state if there is an active DUN connection. It doesn't matter
if this computer is running Windows 2000 Pro, Windows XP Pro, or Windows
XP Embedded -- if there is an active DUN connection, standby will not
happen.

If this functionality documented any where? Or is this an anomaly with
DUN?

And to answer your question "why would anyone want their computer to
enter standby with an active DUN connection?" The answer is that we
have a solution whereby a background process (when awake) polls a remote
system and sends/receives any waiting "messages". The people who this
solution are used to placing their portable computer down for 30 min. or
so, having the system enter standby, and upon re-awakening, start
polling again.

Oh, and original sulution was Windows CE based but now there is a move
to standardize on Windows XP; hence the "new" issue with DUN.

 

[Christopher Luther]

Is there any other Microsofty out here who can confirm or deny that an
active DUN connection prevents automagic System Standby (i.e., Suspend) from
occurring?

- Christopher

Sorry, but I see this as the exception to the rule, not the rule itself.
I don't think it's anything you can alter in any case.

[snip...]

 

[Richard G. Harper]

Microsoft does not monitor these newsgroups, if you want a more official
answer you'll have to pay for it. Sorry.

--
Richard G. Harper [MVP Shell/User] (e-mail address removed)
* PLEASE post all messages and replies in the newsgroups
* for the benefit of all. Private mail is usually not replied to.
* My website, such as it is ... http://rgharper.mvps.org/
* HELP us help YOU ... http://www.dts-l.org/goodpost.htm

Is there any other Microsofty out here who can confirm or deny that an
active DUN connection prevents automagic System Standby (i.e., Suspend)
from occurring?

- Christopher

Sorry, but I see this as the exception to the rule, not the rule itself.
I don't think it's anything you can alter in any case.

[snip...]

 

[Richard G. Harper]

OOPS - Wrong newsgroup. They do spend some time here. Maybe one will
answer.

--
Richard G. Harper [MVP Shell/User] (e-mail address removed)
* PLEASE post all messages and replies in the newsgroups
* for the benefit of all. Private mail is usually not replied to.
* My website, such as it is ... http://rgharper.mvps.org/
* HELP us help YOU ... http://www.dts-l.org/goodpost.htm

Is there any other Microsofty out here who can confirm or deny that an
active DUN connection prevents automagic System Standby (i.e., Suspend)
from occurring?

- Christopher

Sorry, but I see this as the exception to the rule, not the rule itself.
I don't think it's anything you can alter in any case.

[snip...]