Motorola Q "Spurious private messages" firmware bug (confirmed by Motorola)
The PocketTV Team
(confirmed by Motorola) here:
The PocketTV Team
I think MSFT should add a test to check that applications do not receive
messages (e.g. broadcast messages) in ranges that are not allowed, i.e.
(0x8000 through 0xBFFF) and maybe even (0xC000 through 0xFFFF).
This is a simple test that would have cought that one before hitting the
street. The test could be implemented in "hopper.exe". Of course, pressing
all hardware keys and triggering events like charge full, car kit status
changed, earphone or speakerphone status change, phone flipped open/close
etc would be necessary to cathch this type of bug.
We have noticed that on various devices (including the Motorola Q), apps
receive messages in the range 0xC000 through 0xFFFF, which are defined by
MSFT as:
"Message numbers in the fourth range (0xC000 through 0xFFFF) are defined at
run time when an application calls the RegisterWindowMessage function to
retrieve a message number for a string. All applications that register the
same string can use the associated message number for exchanging messages.
The actual message number, however, is not a constant and cannot be assumed
to be the same between different sessions."
Since those messages are received by applications that did not call the
RegisterWindowMessage function, i wonder why apps receive them, and if this
is also also caused by platform bugs.
Norman Diamond
news:OihbHUL...@TK2MSFTNGP05.phx.gbl...
>I cannot believe that this bug was not caught by the MSFT Platform tests.
Is there a way to tell the platform test environment which registered user
messages are intended for broadcast and which ones aren't?
If a program broadcasts a Windows message which wasn't designed for
broadcast then that's a bug. Most Windows messages weren't designed for
broadcast. Some were. It seems pretty hard to construct a list of which
ones were, since even a famous Microsoft blogger omitted at least one that
MSDN describes. This question gets harder for registered user messages.
MSDN can't say which messages the developer designs to be used as broadcasts
and which ones not.
> We have noticed that on various devices (including the Motorola Q), apps
> receive messages in the range 0xC000 through 0xFFFF, which are defined by
> MSFT as:
>
> "Message numbers in the fourth range (0xC000 through 0xFFFF) are defined
> at run time when an application calls the RegisterWindowMessage function
> to retrieve a message number for a string. All applications that register
> the same string can use the associated message number for exchanging
> messages.
Yup. And applications which aren't designed to handle it should forward it
to DefWindowProc. Even within an application, the developer might design
some window procs to do some action when they receive the message and might
not design other window procs to do so. Similarly, some functions (in the
same application or different application) might send the message when a
suitable situation arises, and other functions might not be involved with
that situation at all so they don't send this message. That's programming.
> Since those messages are received by applications that did not call the
> RegisterWindowMessage function, i wonder why apps receive them, and if
> this is also also caused by platform bugs.
If the sender didn't do a broadcast then it looks like a platform bug. If
the sender did do a broadcast then you have to look at the sender's design
to see if it's a bug in the app or not.
The PocketTV Team
> messages are intended for broadcast and which ones aren't?
i'm not sure i understand your question, but i can tell you that no message
in the range [0x8000 to 0xBFFF] are EVER supposed to be broadcast to
applications that did not register to a particular service and expect to
receive them.
i don't think that messages [0xC000 to 0xFFFF] should be broadcast either to
apps that don't expect them, but the MSFT documentation is not totally clear
for the messages in this range.
> If a program broadcasts a Windows message which wasn't designed for
> broadcast then that's a bug.
yes. and broadcasting messages 0x00008015, 0x00008016 and 0x00008017 to all
applications is definitely a bug, and Motorola has (privately) acknowledged
that this is a bug in the Motorola Q firmware.
> Most Windows messages weren't designed for
> broadcast. Some were.
None of them should be in the range [0x8000 to 0xFFFF] according to the
Microsoft documentation (see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesmessages/wm_app.asp )
> It seems pretty hard to construct a list of which
> ones were, since even a famous Microsoft blogger omitted at least one that
> MSDN describes. This question gets harder for registered user messages.
> MSDN can't say which messages the developer designs to be used as
> broadcasts
> and which ones not.
yes, and i find strange that some service, when you register, will send you
predefined messages in the range [0x8000 to 0xBFFF], such as
WM_FILECHANGEINFO or PIM_ITEM_CREATED_REMOTE .
>> We have noticed that on various devices (including the Motorola Q), apps
>> receive messages in the range 0xC000 through 0xFFFF, which are defined by
>> MSFT as:
>>
>> "Message numbers in the fourth range (0xC000 through 0xFFFF) are defined
>> at run time when an application calls the RegisterWindowMessage function
>> to retrieve a message number for a string. All applications that register
>> the same string can use the associated message number for exchanging
>> messages.
>
> Yup. And applications which aren't designed to handle it should forward
> it
> to DefWindowProc.
yes, but why should they receive such messages if they have not registered
to receive them? (e.g. 0xC0003 on the Motorola Q).
> Even within an application, the developer might design
> some window procs to do some action when they receive the message and
> might
> not design other window procs to do so. Similarly, some functions (in the
> same application or different application) might send the message when a
> suitable situation arises, and other functions might not be involved with
> that situation at all so they don't send this message. That's
> programming.
>
>> Since those messages are received by applications that did not call the
>> RegisterWindowMessage function, i wonder why apps receive them, and if
>> this is also also caused by platform bugs.
>
> If the sender didn't do a broadcast then it looks like a platform bug. If
> the sender did do a broadcast then you have to look at the sender's design
> to see if it's a bug in the app or not.
the sender did a broadcast, and this is the bug!
NO-ONE - including Platform services - should EVER broadcast messages in the
range [0x8000 to 0xBFFF] - and probably also [0xC000 to 0xFFFF] -
indiscriminately to all applications that are running on the platform.
This is not permitted by the Microsoft documentation. The range [0x8000 to
0xBFFF] is clearly defines are RESERVED for PRIVATE USE for applications,
and NOT used for system messages...
I know that messages WM_FILECHANGEINFO or PIM_ITEM_CREATED_REMOTE slightly
contradict the MSFT documentation, but they can only be received if you
register to some service.
The PocketTV Team
> design
> to see if it's a bug in the app or not.
In that case, the sender is a Platform service (e.g. a driver), so it is
clearly a bug...
If it was an application that was broadcasting this message, it would be a
bug in the application, but that's not the case. It's a Platform bug.
Norman Diamond
[Norman Diamond]
>> Is there a way to tell the platform test environment which registered
>> user messages are intended for broadcast and which ones aren't?
>
> i'm not sure i understand your question, but i can tell you that no
> message in the range [0x8000 to 0xBFFF] are EVER supposed to be broadcast
I agree with that because that range is defined for messages within an app,
and it is allowable for two separate apps to coincidentally choose the same
number for unrelated meanings within each app.
Hmm, OK, now I agree with you that platform test environment ought to be
able to detect a broadcast of a message number in the range 0x8000 to 0xBFFF
and call that broadcast a bug.
> i don't think that messages [0xC000 to 0xFFFF] should be broadcast either
> to apps that don't expect them, but the MSFT documentation is not totally
> clear for the messages in this range.
On this I have the opposite impression. Apps call RegisterWindowMessage to
learn the identifying number of a message that they want to process. Apps
that don't know that message number aren't involved and they should just
forward such messages to DefWindowProc. The sender has to broadcast because
the sender doesn't know which apps want to receive it and which don't. If
recipient apps were supposed to inform the sender in some way that they want
to be added to a list of recipients that the sender will loop through, then
they would have better ways of communicating ... though I guess sometimes
they would want to reserve a message number anyway.
>> Most Windows messages weren't designed for broadcast. Some were.
>
> None of them should be in the range [0x8000 to 0xFFFF] according to the
> Microsoft documentation (see
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesmessages/wm_app.asp )
In that page I don't see any statement about broadcasts. In order to agree
with you about the range 0x8000 to 0xBFFF I had to do some intuitive
analysis of the way apps use that range. I don't agree with you about the
range 0C000 to 0xFFFF.
>> It seems pretty hard to construct a list of which ones were, since even a
>> famous Microsoft blogger omitted at least one that MSDN describes. This
>> question gets harder for registered user messages. MSDN can't say which
>> messages the developer designs to be used as broadcasts and which ones
>> not.
>
> yes, and i find strange that some service, when you register, will send
> you predefined messages in the range [0x8000 to 0xBFFF], such as
> WM_FILECHANGEINFO or PIM_ITEM_CREATED_REMOTE .
In these cases, when you say "register", you don't mean calling
RegisterWindowMessage, you mean doing something to ask the sender to send
these messages. It seems to me that if you don't ask for these messages
then you don't get them, and this means that the sender isn't broadcasting
them.
The PocketTV Team
messages in [0x8000 to 0xBFFF].
regarding [0xC000 to 0xFFFF], i am not completely clear, but my
understanding of the MSFT documentation is that i should not receive them if
i have not registered with RegisterWindowMessage to receive them.
but on the Q, even though I have never called RegisterWindowMessage, I do
receive messages in the range [0xC000 to 0xFFFF]. i have never done
anything to ask messages in this range.
you say: "On this I have the opposite impression. Apps call
RegisterWindowMessage to
learn the identifying number of a message that they want to process. Apps
that don't know that message number aren't involved and they should just
forward such messages to DefWindowProc. "
my impression is the opposit: Apps call RegisterWindowMessage to get the
messages. if they don't call RegisterWindowMessage, they should not receive
those messages.
definitely the MSFT documentation is not clear regarding [0xC000 to
0xFFFF].
but it is pretty clear regarding [0x8000 to 0xBFFF], and those messages
should never be sent or broadcast to all apps, or sent to apps that don't
have some private understanding of what they mean.
"Norman Diamond" <ndia...@community.nospam> wrote in message
news:%23a4wiCw...@TK2MSFTNGP02.phx.gbl...
Norman Diamond
> so we completely agree that there is a platform bug on the Q regarding
> messages in [0x8000 to 0xBFFF].
Yes.
> regarding [0xC000 to 0xFFFF], i am not completely clear, but my
> understanding of the MSFT documentation is that i should not receive them
> if i have not registered with RegisterWindowMessage to receive them.
I am clear. RegisterWindowMessage tells you what number Windows is
assigning to the name for this session. An absence of calling
RegisterWindowMessage only yields an absence of knowing the number. Anyone
(your application or others) can call SendMessage or PostMessage etc. If
know your window handle they can even single you out and send you the
message without caring whether you've called RegisterWindowMessage or not.
> my impression is the opposit: Apps call RegisterWindowMessage to get the
> messages. if they don't call RegisterWindowMessage, they should not
> receive those messages.
Then you've pretty well misunderstood that API.
Maybe you want an ACL to be added to each window handle, listing the window
message numbers that this window is willing to accept, and for each message
number then listing which accounts it's willing to accept that kind of
message from. In ordinary Windows systems this could be a way of reducing
shatter attacks. Anyway Windows doesn't give us this.
The PocketTV Team
>> messages in [0x8000 to 0xBFFF].
>
> Yes.
good! - that was the main point of my bug report.
regarding [0xC000 to 0xFFFF], all i am saying is that the MSFT documentation
is unclear regarding the fact that applications should expect to receive
system messages in this range (i.e. that's what we observe on the Q), that
they should - of course - pass to the default window procedure.
my understanding (from reading the MSFT documentation) was that those
messages are reserved for use with RegisterWindowMessage, i.e. two apps
that want to communicate privately can call RegisterWindowMessage and then
use the message number that RegisterWindowMessage indicated to communicate
between each other.
so if your interpreration is the right one (i.e. the system is allowed to
broadcast messages in the range [0xC000 to 0xFFFF] to all applications),
then the documentation for [0xC000 to 0xFFFF] is misleading, IMHO (see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesmessages/wm_app.asp )
Norman Diamond
>>> so we completely agree that there is a platform bug on the Q regarding
>>> messages in [0x8000 to 0xBFFF].
>>
>> Yes.
>
> good! - that was the main point of my bug report.
>
> regarding [0xC000 to 0xFFFF], all i am saying is that the MSFT
> documentation is unclear regarding the fact that applications should
> expect to receive system messages in this range (i.e. that's what we
> observe on the Q), that they should - of course - pass to the default
> window procedure.
The messages aren't system messages, they're application messages with
numbers assigned by the system on request from applications.
The same kind of intuitive analysis that yielded a conclusion that 0x8000 to
0xBFFF shouldn't be broadcast also yields a conclusion that 0xC000 to 0xFFFF
are fine for broadcast.
> my understanding (from reading the MSFT documentation) was that those
> messages are reserved for use with RegisterWindowMessage, i.e. two apps
> that want to communicate privately can call RegisterWindowMessage and
> then use the message number that RegisterWindowMessage indicated to
> communicate between each other.
I agree. Furthermore the two (or more) apps don't know each others' window
handles, so broadcasting doesn't seem unreasonable.
> so if your interpreration is the right one (i.e. the system is allowed to
> broadcast messages in the range [0xC000 to 0xFFFF] to all applications),
I think it would be a bit abusive for the system to do that. The system is
supposed to use the user range and below. (i.e. 0x0000 to 0x7FFF, but I
couldn't resist sharing a snark about the user range.)
> then the documentation for [0xC000 to 0xFFFF] is misleading, IMHO (see
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesmessages/wm_app.asp )
I don't see what's misleading about it. I didn't see any approval or
disapproval of broadcasting in that page. We just have to think about what
is reasonable for apps to do privately and what is reasonable for apps to do
publicly. The range 0xC000 to 0xFFFF gets registered on request for a
reason, and I think that permits broadcasting.
The PocketTV Team
private messages (in the range [0x8000 to 0xBFFF] to applications.
We just discovered a similar bug on the "Torq P100" aka "E-TEN M500" Pocket
PC!
The device where the bug was observed is a E-TEN M500. On this device,
apparently all running applications receive a message 0x8017 with lParam and
wParam set to 0 each time the user opens the Contacts application.
Our latest version of PocketTV (1.2.14) catches those spurious messages and
displays an error message in a pop-up, and the problem was reported today by
a E-TEN M500 user in India.
So clearly this indicates that MSFT has no platform test to check that the
platform does not send spurious messages to running applications. This is a
pretty serious testing issue that MSFT should address, since at least two
devices have that bug!
And again, all applications that use private messages in the range [0x8000
to 0xBFFF] for inter-thread communications should be aware of the issue, and
work around it on the devices that have the bug.