Windows Mobile "Spurious private messages" firmware bug

[Guest The PocketTV Team]

Windows Mobile "Spurious private messages" firmware bug

There is a confirmed serious firmware bug in the Motorola Q and other Windows Mobile devices that developers must be aware of, and work around in case their applications are affected by the bug.

Description of the firmware bug:

The system (or drivers) incorrectly broadcasts messages in the range [WM_APP (i.e. 0x8000) to 0xBFFF] to all running applications.

On the Motorola Q, the spurious messages are 0x00008015, 0x00008016 and 0x00008017. They may be different on other affected devices.

The problem is that those messages are in the range [WM_APP (i.e. 0x8000) to 0xBFFF] which is normally reserved for private messages and used typically for private inter-thread communication inside an application.

See WM_APP documentation here: http://msdn.microsoft.com/library/default....ages/wm_app.asp

Those messages [WM_APP to 0xBFFF], according to MSFT documentation, are never sent by the system to an application unless the application has registered to some service and is expecting them and knows the private meaning of the message. In some cases (e.g. WM_FILECHANGEINFO or PIM_ITEM_CREATED_REMOTE) those messages can be received if the app has registered to a particular system service.

The Microsoft documentation states: Message numbers in the third range (0x8000 [WM_APP] through 0xBFFF) are available for application to use as private messages. Message in this range do not conflict with system messages.

Therefore on the affected devices (Motorola Q, O2 Zinc, etc, see list below), any application that uses messages in the range [WM_APP to 0xBFFF] for private inter-thread communication may potentially be affected by this firmware bug. Usually when a thread receives one of the spurious private message from the system, it will misbehave or crash, causing random application behavior (most likely freezing or crashing).

On the Motorola Q, those "Spurious private messages" are:

#define TM_HEADSET_CHANGE			(WM_APP+21)	 // 0x00008015 - Headset state has changed (inserted or removed)

#define TM_CARKIT_CHANGE			 (WM_APP+22)	 // 0x00008016 - Carkit state has changed (inserted or removed)

#define TM_SPEAKER_CHANGE			(WM_APP+23)	 // 0x00008017 - Speaker phone state changed (user pressed pac-man key on keyboard)

and they are sent to all applications when one of those events occurs (e.g. Speaker phone state changed). On other devices, spurious messages are sent in other situations, e.g. on the Palm Treo 500v, spurious messages occur when a phone call is made. How to observe the bug: 1) Create the simple "hello world" C++ application using the VS2005 wizard: New Project > Smart Device > Win32 Smart Device Project. 2) In the message loop, just insert 3 lines to print a message when a spurious private message is received:

while (GetMessage(&msg, NULL, 0, 0)) {

	if (msg.message >= 0x00008000 && msg.message <= 0x0000BFFF) {

		OutputDebugString(TEXT("bingo\n"));

	}

...

}

3) Run the "hello world" app on your device.

To reproduce the problem on the Motorola Q, press the "Speakerphone" key on the bottom-right of the keyboard (the key with a pac-man icon). Look for "Bingo" in the debug output. Simple!

Workaround:

The workaround is simple: Modify your application so that it does not use any of the spurious messages for private inter-thread communication, and ignore those spurious messages when you receive them. The problem of course is that various devices can send various spurious private messages. So it's a bit of a guessing game.

Also, never use messages in the range (0xC000 through 0xBFFF) for private inter-thread communication, since applications also receives some of those messages (not sure if this is also a bug, see more on that in the "Misc" section below).

Misc:

1) Known Windows Mobile that are affected by this bug include:

- Samsung i-600

- Asus P525, P535, P750

- E-Ten M500, M700, G500, G500_PLUS, X500

- O2 Xda Zinc

- Motorola Q

- HTC Hermes

- Palm Treo 500v

- HP iPaq h500

2) We don't know if this bug affects C# applications or applications using other run-time engines (e.g. Java).

3) We have worked with Motorola Engineering team on this issue, and they have privately acknowledged the problem on the Q. The problem apparently affects all production units of the Motorola Q, so it affects potentially hundreds of thousands of units, if not millions. Whether the bug is fixed in later releases of the Motorola Q firmware is almost irrelevant, since affected applications must handle all the devices that have the bug.

4) We need to make this problem known to all Windows Mobile developers, otherwise a number of apps will crash and/or misbehave on the affected devices, unless they are modified to work around this problem. and due to the nature of the problem, developers have no easy way to understand the cause of the problem, as it looks like random crashes.

5) I cannot believe that this bug was not caught by the MSFT Platform tests. 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. This is a simple test that would have cought that one. 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.

6) We have noticed that on various devices (including the Motorola Q), apps also receive private 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.

7) To detect the Device Model (if you need to), use SystemParametersInfo(SPI_GETOEMINFO, ...). The OEMINFO string for the Motorola Q is: "MotoQ". For the O2 Xda Zinc it is "O2Zinc" or "O2 Xda Zinc". For the HTC Hermes it is "HERM100".

8) Here are the versions of the Motorola Q production model that we have used to validate this bug:

Settings->Phone Information->Software version:

Q2-BP_C_04.08.04P

MP_BSP_C_01.07.05-08P_HW_P2.1

Settings->about:

OS version: 5.1.70 (Build 14523.1.3.0)

9) Our applications (PocketTV Classic freeware and PocketTV Enterprise Edition), which were affected by the bug, now use the workaround (you need version 1.2.10 if you have a Motorola Q). Download are available from the links above or from http://www.pockettv.com .

10) Thanks to the Motorola Engineering team for helping us indentifying this bug. And thanks to Motorola for providing us with a test device.

11) Newgroup discussion on this topic: http://groups.google.com/group/microsoft.p...c78007c7193d4f8

Edited April 7, 2008 by The PocketTV Team

[Guest The PocketTV Team]

The "Motorola Q" is not the only Windows Mobile device that sends spurious 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!

See details here: http://www.modaco.com/index.php?showtopic=243248

Edited July 24, 2006 by The PocketTV Team

[Guest The PocketTV Team]

we just confirmed that the Samsung i-600 has the same firmware bug than the Motorola Q, i.e. it sends spurious private messages to the applications.

this firmware bug is documented here: http://www.modaco.com/Motorola-Q-Spurious-...la-t242539.html

in the case of the Samsung i-600, the spurious messages are sent when the phone is flipped open or closed. the message sent to all application is 0x000080ca - which is a value reserved for private use (e.g. interthread-communications) inside applications and should NEVER be sent to an application unless it expects this message to be sent.

this can cause applications to randomly crash or misbehave when the Samsung i-600 is flipped closed or opened.

i think that the Samsung i-600 is also known as the Sprint PCS Vision Smart Device SP-i600 (as we had other reports of this from people using this device).

we have received reports that the same firmware bug also affects the Asus P525.

it is very important that MSFT makes sure that they tests this in their platform validation tests.

Edited December 22, 2006 by The PocketTV Team

[Guest The PocketTV Team]

We have been notified that the Eten M700 (Windows Mobile 5) has this bug, too.

Edited March 1, 2007 by The PocketTV Team

[Guest The PocketTV Team]

We have been notified that the O2 Xda Zinc (designed by Asus) has this bug, too.

On the O2 Xda Zinc , applications receive the spurious message 0x00008017.

Edited February 28, 2007 by The PocketTV Team

[Guest The PocketTV Team]

We have just been notified that the Asus P535 (Windows Mobile 5) has this bug, too.

On the Asus P535, applications receive the spurious messages 0x00008015 and 0x00008017.

[Guest The PocketTV Team]

We have just been notified that the HTC Hermes Pocket PC (Windows Mobile 5) has this bug, too.

On the HTC Hermes , applications receive the spurious message 0x00008101.

[Guest Dumdidum]

Hello

We have a bug in a .NET Application on HTC S710-Devices (we've tested several), and it is happening only on this device yet. First we thought that it is something with WM 6.0, but all Emulators are working correctly and also another phone with WM 6.0.

We just cannot send keystrokes anymore, as we could do it on all other devices.

Maybe this has the same reason as your bug?

We are testing further, and hope that we can track it down soon...

Sven

[Guest The PocketTV Team]

Maybe this has the same reason as your bug?

it is possible, but it could be also a completely un-related reason that causes your problem.

[Guest colinmunro]

6) We have noticed that on various devices (including the Motorola Q), apps also receive private messages in the range 0xC000 through 0xFFFF, which are defined by MSFT as:

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.

In this regard I think it's okay - from what I recall there's a few places in the documentation that talk about receiving notifications of certain system events, and the way you receive them is to simply call RegisterWindowMessage() with the Microsoft-assigned name of the event. Presumably these work by the system calling RegisterWindowMessage() with the name, then just broadcasting the newly assigned message to all apps - apps that don't want the message would always have received it, but if they follow the rules, should only ever be expecting messages in that range they got from RegisterWindowMessage() anyway.

Basically, RegisterWindowMessage() doesn't register an interest like an observer-type model, it just gets a unique WM_message for a unique string.

[Guest The PocketTV Team]

apparently some Motorola Q devices with WM5 broadcast also the following spurious message to applications:

msg = 0x00008064, wParam = 48 (0x00000030) , lParam = 0 (0x0000000)

this information is based on an un-confirmed user report.

Edited June 26, 2007 by The PocketTV Team

[Guest The PocketTV Team]

This bug has been reported on the Treo 500v (identified by the OEM string Treo 500v-1.02).

The spurious message received is msg 0x00008017, wParam 0 (0x00000000), IParam 0 (0x00000000)

This spurious message is received by applications after a phonecall is performed on this mobile.