Autorun and digital signature (1)

What should I do if the system you are responsible for encounters an inexplicable exception? In other words, how do you locate the problem and solve the problem? For this type of problem, I am most concerned about the internal running status of the system. It is helpful to find out the root cause of the problem if you can figure out the current status of the system. Tools must be used to obtain the running status of the system. On Windows desktop systems, simple tasks such as task manager and spy ++ of VC must be used, advanced Process Explorer/Process Monitor for sysinternals are useful runtime analysis tools. On Windows CE, these tools include process viewer, kernel tracker, and my remote process Explorer (which is one of my purposes for writing this tool. The problem is that the user interfaces of most Windows CE-based devices are customized. Unlike Windows desktop systems that have a shell, you can run whatever you like. For this type of devices, you need to find a way to run the program by neither increasing the burden on the system nor obtaining system control when necessary.

For devices that support mobile storage (such as USB flash drives, SD cards, and CF cards), I think Autorun technology is a very powerful method. Then, it runs. It is very simple but practical, similar to the CD/DVD Autorun technology. Windows Mobile directly supports Autorun. In fact, it is easy to implement on Windows CE: runtime runs.

To implement this function, you must first create a message queue during initialization to wait for the system device plugging time notification:

Code
Struct mydev {
Union {
Devdetail dev;
Byte Buf [sizeof (devdetail) + sizeof (tchar) * max_devclass_namelen];
};
};

Msgqueueoptions msgoptions;
Handle HQ, HN;
// Initialize File System notification stuff
Memset (& msgoptions, 0, sizeof (msgoptions ));
Msgoptions. dwsize = sizeof (msgoptions );
Msgoptions. dwflags = 0;
Msgoptions. dwmaxmessages = 20;
Msgoptions. cbmaxmessage = sizeof (mydev );
Msgoptions. breadaccess = true;
HQ = createmsgqueue (null, & msgoptions );
If (HQ)
{
HN = requestdevicenotifications (& fatfs_mount_guid, HQ, true );
If (HN)
Setevent (HQ );
}

Then, in the thread loop, use waitforsingleobject to wait and process the event:

Code
If (wait_object_0 = waitforsingleobject (HQ, infinite ))
{
DWORD dwbytesreturn;
DWORD flags;
Mydev detail;
While (readmsgqueue (HQ, & detail, sizeof (detail), & dwbytesreturn, 0, & flags ))
{
If (detail. Dev. fattached & isw.guid (fatfs_mount_guid, detail. Dev. guiddevclass ))
{
Retailmsg (1, (text ("found storage device: % s \ r \ n"), detail. Dev. szname ));
// Handlemountedstoragedevice (detail. Dev. szname );
}
}
}

The key points are,

1. Define a mydev structure to receive messages;
2. Use createmsgqueue to create a message queue to receive system messages;
3. Use requestdevicenotifications to receive messages of the fatfs_mount_guid type. This means that all messages of the FAT file system mount and unmount will be notified (the FAT file system is generally used for USB flash drives and various memory cards );
4. Waiting for notification with waitforsingleobject does not impose any additional burden on system performance. If there are multiple events, you can use waitformultipleobjects. If there are other Windows messages to be processed (such as in the main thread loop), you can use msgwaitformultipleobjects;
5. After that, read the message using readmsgqueue and use isequalguid to determine the Message Type and then process it.