News + Articles
Sign In
Create Account
2
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.microsof...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:
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:
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:
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:
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...c78007c7193d4f8
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.microsof...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:
Quote
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.
to be the same between different sessions.
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:
Quote
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)
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)
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...c78007c7193d4f8
Edited by The PocketTV Team, 07 April 2008 - 08:45 AM.
Back to top
