Windows CE Networking Team WebLog : Author: David Kanz

Memory Corruption, Compiler Bug, Or Not?

cenet — Tue, 23 Oct 2007 04:16:00 GMT

While tracking down some memory corruption issues, I noticed in one function that a parameter on the stack was always getting set to the value 2, even though it was a pointer. I could see it turn red in the memory view window as its value changed. I thought I had identified a compiler bug. But no, it was not a compiler bug. It was actually a mismatch between the optimizing compiler and the debugger. The x86 optimizer knew that the memory for the stack variable was referenced only one time and then was enregistered, so its stack memory could be used for another local variable. The debugger’s local variable display did not realize this and continued to display the memory value for the local variable – confusing.

On ARM, a similar situation can arise since the first 4 registers (R0, R1, R2 and R3) are used as function parameters. The debugger doesn’t track when a function parameter gets moved to a “permanent” register (R6 for instance) and continues to display the function parameter register’s value as the local variable’s value.

Windows CE and the Serial Carrier Detect Signal

cenet — Tue, 24 Jul 2007 22:49:00 GMT

The Windows CE serial port based networking components have an historical affinity for the RS232 Carrier Detect (CD) signal. A key feature of Windows CE 1.0 was automatic synchronization of email and contacts when docked (ActiveSync). The device needed to detect when it was docked, and it needed to wake up when docked. Since this scenario was originally serial port based, CD was used as both the wake-source interrupt and the signal to start the ActiveSync application on the device.

The corresponding components (mostly Unimodem and PPP) in Windows NT/XP/Vista do not rely on CD, so many scenarios that work between non-CE devices do not work the same when a CE device is involved. It is often due to one of the following reasons:

1. The cable being used does not include the Carrier Detect line.

2. The platform specific serial port device driver does not properly report CD status. The serial driver’s SL_GetModemStatus indicates CD state with the MS_RLSD_ON flag for the Win32 serial port API function GetCommModemStatus(). EV_RLSD is used to indicate a change in state of the CD signal.

3. The hardware does not implement the CD signal. If this is the case, then a valid workaround is for the serial port device driver to always indicate that CD is asserted by always setting MS_RLSD_ON in its SL_GetModemStatus function.

PCMCIA Problems on Windows CE Devices.

cenet — Mon, 07 May 2007 20:40:00 GMT

I wrote the first PCMCIA driver for Windows CE in 1995. At the time, CE had not been ported to the PC, so we had to rely on reference platforms and prototypes to debug. Some problems were not software related.

The first Windows CE reference platform was called PeRP (Pegasus Reference Platform, Pegasus was the code name for Windows CE 1.0). The designer did not understand how the software would use the PCMCIA memory mapped regions. He thought he would be thrifty and “save” three gates by making a byte appear at every DWORD address. This is why the CE 1.0 Card Services API included such functions as CardReadAttrByte and CardWriteIOByte. A vestige of this design decision remained until CE 5.0 in CardMapWindow’s pGranularity parameter. On the PeRP, pGranularity would be set to 4 or sizeof(DWORD). On all other platforms it is 1.

The next Microsoft developed reference platform was called the Odo (after a Star Trek character). It had a pluggable CPU architecture so we could test the various processors supported by CE at the time. Those in charge of the decision were sometimes too quick to approve a new CPU board. In their view, I guess booting CE to the shell was good enough. The PCMCIA support always seemed to get overlooked. I was left scrambling to figure out another reason why PCMCIA was failing on yet another Odo CPU board. I became quite adept at setting up the logic analyzer for monitoring the PCMCIA bus, and adept at reading the traces. Sometimes this wasn’t enough.

On one flavor of MIPS CPU board for Odo, some cards would work fine, and others would get recognized, but then could not be used in I/O mode. By simply reading some of the PCMCIA lines with a multi-meter we found that the power lines had not even been attached! The cards were being powered by the address lines! This of course limited the amount of power available to the card. Any card requiring more than a certain amount of power would not work in I/O mode. A card in memory mode (the initial mode a card is in when first inserted) has minimal power requirements since the attribute memory is usually a small ROM. I/O mode usually requires much more power. The amount of power varies from one card to another. This is why some worked and others did not.

I have encountered many similar power related problems. Much of the time the root cause is that the batteries cannot supply enough power for the card. A closely related problem is that the device on battery power cannot power a card to operating voltage in enough time. That is why there is the power-on delay registry setting. Often, plugging in the A/C power adapter provides enough power in these cases.

Another interesting problem had nothing to do with the PCMCIA controller hardware implementation and nothing to do with power. In version 1.0, CE did not support 16 bit I/O on PCMCIA. When support for it was added, there were some platforms that had problems. When I finally put the logic analyzer to work, I discovered that accesses to some byte-wide registers were not appearing in the trace. There were only 16 bit accesses. Configuring the software for the platform to report support for only 8 bit PCMCIA I/O obviously worked since the platform worked with CE 1.0. A visit to the MIPS architecture manual revealed the reason – MIPS has no instructions for byte-wide memory accesses! On MIPS, you either support 16 bit PCMCIA access or 8 bit, but not both. The same MIPS instruction is used for both; the PCMCIA subsystem generates an 8 bit access on the PCMCIA bus if it is configured for 8 bit. Many card designs are modeled from PC (x86) architecture designs and so they freely allow mixed 8 and 16 bit I/O accesses, often to the same register. Because of this a MIPS based device almost always has to support 8 bit only PCMCIA I/O.

Windows CE IRDA Architecture

cenet — Fri, 09 Feb 2007 23:33:00 GMT

The IrDA related Windows CE components are Irdastk.dll, Ircomm.dll and an IrDA NDIS miniport driver - typically Irsir.dll is used. For platforms with DMA based IrDA hardware, a platform specific IrDA NDIS miniport driver will be used.

Protocol Driver

The irdastk.dll component implements the IrDA protocol. It provides support for AF_IRDA Winsock sockets. It is an NDIS protocol driver and it binds to an underlying NDIS IrDA miniport driver.

Serial Based NDIS IrDA Miniport Driver

The irsir.dll component is a special IrDA NDIS miniport driver that talks to IrDA hardware that is exposed as a serial port. Early in IrDA history, it was appropriate to expose the IrDA hardware as a special serial port due to the lower speeds and simpler hardware abstraction. When irdastk.dll binds to the irsir.dll NDIS miniport, irsir.dll converts the NDIS miniport driver commands into appropriate Win32 serial port function calls. For instance, when irdastk.dll calls NdisSend(), NDIS routes the call to irsir.dll’s miniport SendHandler which in turn calls WriteFile() on the Irda serial port.

Many Windows Mobile devices still expose their IrDA hardware as a serial port.

Virtual Serial Port

The ircomm.dll component implements a virtual serial port. A serial port based application can communicate over IrDA without change just by using the serial port presented by ircomm.dll (i.e. “COM3:”). For each Win32 serial port function, ircomm.dll calls an appropriate AF_IRDA Winsock function. For instance, if an application calls WriteFile() using the ircomm.dll serial port handle, it causes ircomm.dll to call the Winsock send() function.

The serial port presented by Ircomm.dll has the index found under the registry key [HKEY_LOCAL_MACHINE\Drivers\Builtin\Ircomm] in the REG_DWORD value named “Index”.

Configuring TAPI line devices in Windows CE

cenet — Wed, 22 Nov 2006 04:52:00 GMT

In Windows CE, TAPI listens for device plug and play notifications. When it gets notified of a new device, it looks in the device driver’s key and subkeys for a REG_SZ value named Tsp. If it is found, it specifies the dll name of a TSP (TAPI Service Provider, for instance, unimodem.dll) to be associated with this device. TAPI loads the TSP and calls both its TSPI_providerCreateLineDevice and TSPI_providerCreatePhoneDevice functions with 3 parameters: a handle to the new device’s “active” registry key (i.e. HKEY_LOCAL_MACHINE\Drivers\Active\NN), the device driver registry key path string, and the new device’s name.

Take for example, a new serial driver, BSPSerial.dll. Its device driver key would look something like this:

[HKEY_LOCAL_MACHINE\Drivers\Builtin\BSPSerial]

“Dll”=”bspserial.dll”

“Prefix”=”COM”

“Index”=dword:1

“DeviceArrayIndex”=dword:0

To expose it as a null modem Unimodem controlled TAPI line device, add this key and these values:

[HKEY_LOCAL_MACHINE\Drivers\Builtin\BSPSerial\Unimodem]

“Tsp”=”unimodem.dll”

“DeviceType”=dword:0

(DeviceType == 0 means null modem, see unimodem.h for the complete list of values)

Additionally, BSPSerial could be exposed as a Hayes compatible Unimodem controlled TAPI line device by adding this key:

[HKEY_LOCAL_MACHINE\Drivers\Builtin\BSPSerial\UnimodemHayes]

“Tsp”=”unimodem.dll”

“DeviceType”=dword:1

These two subkeys of BSPSerial will cause two TAPI line devices to appear when BSPSerial’s COM1: device is created.

In the first version of Windows CE, the unimodem device settings were located directly in the device driver key. This limited TAPI configurability by not allowing multiple TSPs to use the same device and by not allowing multiple unimodem line device types on the same device. This configuration is still allowed, although discouraged.

For unimodem, this limitation was overcome with the HKEY_LOCAL_MACHINE\ExtModems key. Unimodem.dll reads this key immediately after system initialization and instantiates the line devices listed.

Author: David Kanz

TAPI Resource Cleanup

cenet — Sat, 17 Jun 2006 01:49:00 GMT

TAPI maintains its resources in a hierarchy and will perform automatic cleanup based on the hierarchy of objects.

The top of the TAPI resource hierarchy is the HLINEAPP which represents a TAPI client application instance. It is returned from lineInitialize and lineInitializeEx. If the application calls lineShutdown with its HLINEAPP, then all TAPI resources associated with the HLINEAPP will be deleted. An application may have more than one HLINEAPP.

The next level of the TAPI resource hierarchy is the HLINE which represents an open handle to a TAPI line device, returned from lineOpen. An HLINE is closed with lineClose.

Below HLINE is the HCALL which represents an open handle to a call. HCALLs are unique since TAPI will allocate them behalf of an application with an open line device (HLINE) in order to indicate call status messages to the application. An HCALL is also allocated by calling certain TAPI functions, for instance lineMakeCall. An HCALL is closed with lineDeallocateCall. Since TAPI automatically allocates HCALLs for an application, it is most efficient for the application to call lineDeallocateCall when it receives the LINE_CALLSTATE message with the LINECALLSTATE_IDLE state.

The bottom of the hierarchy is the LINEMESSAGE. A LINEMESSAGE may be associated with an HLINEAPP, an HLINE or an HCALL. There is no application control over the allocation or freeing of LINEMESSAGEs. An application needs to be aware that when it closes or frees an HLINEAPP, HLINE or HCALL, then TAPI will delete all pending LINEMESSAGEs associated with that resource. When an application closes one of the higher level objects, it should no longer wait for any messages associated with the object.

In summary:

Closing an HCALL (lineDeallocateCall) deletes all pending LINEMESSAGEs associated with it.

Closing an HLINE (lineClose) closes all HCALLs associated with it.

Closing an HLINEAPP (lineShtudown) closes all associated HLINEs.

In Windows CE, TAPI is implemented as a PSL (Protected Server Library), so it gets a notification when a process terminates. When a process terminates, TAPI closes all HLINEAPPs associated with the process.

Author: David Kanz

TAPI Call Handle Confusion

cenet — Wed, 14 Jun 2006 06:46:00 GMT

TAPI call handles (HCALLs) consume memory and should be closed with lineDeallocateCall when no longer needed.

If an application has a TAPI line device opened (HLINE), then TAPI will allocate call handles on its behalf in order to indicate call status messages to the application. Such an application needs to be aware of this and at the very least process the LINE_CALLSTATE message indicating LINECALLSTATE_IDLE by calling lineDeallocateCall on the HCALL passed as dwParam1. Otherwise, the system will leak almost 200 bytes of memory per call.

For an application using TAPI to control a call, LINECALLSTATE_IDLE is also a good time to call lineDeallocateCall. In this case though, the application needs to be aware that calling lineDeallocateCall will cause TAPI to delete any LINE_REPLY messages for asynchronous operations associated with that HCALL. If the application has a separate thread that calls lineDrop and then blocks waiting for the associated LINE_REPLY, there needs to be coordination with the message handling thread that just called lineDeallocateCall, otherwise the lineDrop thread will block indefinitely.

Author: David Kanz

Pageable Device Drivers

cenet — Wed, 14 Jun 2006 06:05:00 GMT

During the Windows Mobile 5.0 timeframe, we changed most of the networking components to be pageable device drivers. This caused boot times to decrease by a significant amount since there was now more than 2MB extra free RAM.

A device driver can safely be made pageable if:

1. it does not need to do any processing during the critical power down and power up phase (xxx_PowerDown and xxx_PowerUp)

2. it is not involved in the paging process

All that needs to be done to make a device driver pageable is:

remove the xxx_PowerDown and xxx_PowerUp entries from the driver’s .def file
add the value, “Flags”=dword:2, to the device driver’s device key (2 == DEVFLAGS_LOADLIBRARY). By default, a device driver’s DLL is loaded with LoadDriver() which loads it as non-pageable.

In some device drivers the only processing during xxx_PowerDown/Up is to note that the system power mode has changed. Such processing can be replaced with a thread that uses a Message Queue (CreateMsgQueue) which it has passed to the RequestPowerNotifications function, specifying PBT_RESUME. Then it can loop calling ReadMsgQueue.

The PBT_RESUME messages get posted in a timely enough manner that this method is in most cases an adequate replacement for xxx_PowerDown/Up.

Author: David Kanz

About David Kanz

cenet — Wed, 14 Jun 2006 04:59:00 GMT

I'm David Kanz. I've worked at Microsoft since October 19, 1987 - Yes, Black Monday. I initially worked on OS/2 Lan Manager. When the Windows For Workgroups team asked me to join them in 1993, they tried to entice me by talking about Thomas Fenwick's tiny kernel for handheld devices. I was sold. This was to become what we now call Windows CE. When it was announced that the Winpad, Pulsar and At Work FAX teams were being disbanded and rejoined to form what is now Windows CE, I joined as soon as I could.

I initially worked on the drivers team developing the PCMCIA system and helping with other driver issues. Then I switched to the networking team, where I own TAPI, Irda, some Winsock stuff and VoIP, among other things.