A customer contacted me today to ask for help with a Windows CE 3.0 device. Yes, Windows CE 3.0 is alive and kicking on thousands of systems in the field. They were trying to update a driver on the system but the driver wouldn’t load and run. The driver was from a third party who claimed that the driver would run on Windows CE 3.0.
I asked a few questions. Is the driver for CE 3.0? Is the driver dependent on some DLL or APIs that aren’t available? Customers being customers, the best that he could tell me was that the WEB site says it should work.
So I asked him to send the driver to me so that I could take a look at it. When I received the driver, I looked at it with Dumpbin and quickly determined that it wasn’t going to work.
First, I looked at the headers using “dumpbin /HEADERS file.dll” and this is what I found:
Dump of file file.dll
PE signature found
File Type: DLL
FILE HEADER VALUES
1C2 machine (Thumb)
6 number of sections
46A0FA34 time date stamp Fri Jul 20 14:08:52 2007
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
210E characteristics
Executable
Line numbers stripped
Symbols stripped
32 bit word machine
DLL
OPTIONAL HEADER VALUES
10B magic # (PE32)
6.01 linker version
9000 size of code
BE00 size of initialized data
0 size of uninitialized data
1444 entry point (10001444)
1000 base of code
A000 base of data
10000000 image base (10000000 to 10017FFF)
1000 section alignment
200 file alignment
4.00 operating system version
0.00 image version
2.11 subsystem version
0 Win32 version
18000 size of image
400 size of headers
0 checksum
9 subsystem (Windows CE GUI)
0 DLL characteristics
10000 size of stack reserve
1000 size of stack commit
I didn’t include all of the output, but this shows enough to show what I found. The highlighted lines show that this dll was built for Windows CE 4.0 and Thumb. Thumb actually tells us that it was built for ARMV4I, it could have been built for ARM Thumb, but that is unlikely.
Then I ran “dumpbin /DEPENDENTS file.dll”, which output:
Image has the following dependencies:
COREDLL.dll
Which tells me that this dll is dependent on coredll.dll, which is fairly safe because coredll.dll has to be in the OS. But there could be some APIs that aren’t supported by the coredll.dll in the os, so run “dumpbin /IMPORTS file.dll” to find which APIs it needs:
Section contains the following imports:
COREDLL.dll
1000B000 Import Address Table
1000A6C4 Import Name Table
0 time date stamp
0 Index of first forwarder reference
Ordinal 36
Ordinal 33
Ordinal 1044
Ordinal 63
Ordinal 492
Ordinal 495
Ordinal 529
Ordinal 530
Ordinal 528
Ordinal 60
Ordinal 494
Ordinal 553
Ordinal 497
Ordinal 717
But that also makes this more of a challenge. Instead of function names, the ordinal values are listed. No worries if you saved the coredll.def that was created when the OS was built. All that has to be done is to look up the ordinal values in coredll.def to see if they are all available.
So that is how I used Dumpbin to help a customer today.
Copyright © 2009 – Bruce Eitman
All Rights Reserved