Tech support, part 2

Today, my new box finally arrived on my doorstep. However, suspense quickly turned into disappointment when I unpacked the box. Something was loose inside. I opened the case, and discovered that the harddisk was lying on the motherboard. Apparently, they forgot to use a screw to keep the raptor in it's place. I quickly checked for damage, and noticed that a power supply connector was broken and a part of the case was broken. Also, 1 RAM memory bank took a hit and the RAM wasn't connected properly anymore, and my SATA cables where no longer plugged in.

So I fixed everything and tried the PC to see if everything was working. It looked ok in the beginning, but suddenly after 1 or 2 minutes during Vista setup, the video was gone. Opened the box and noticed that the fan of the 8600 didn't work. Apparently, it also took a hit from the HD.



So basically, everything except my DVD writer was broken in one way or another. I closed the box and put it back in it's packaging. I contacted the shop, and I wonder how they will react. I'm VERY close to asking a refund and spending my money some place else.

Tech support (warning: rant ahead)

In my previous post, I talked about buying a new development box. Well, I'm still waiting for it. What happened?

I ordered the PC on Thursday, the 10th of May. I made sure to choose components that where in stock. I payed by wire transfer immediately.

After a week, they informed me that they received the money. This should have been on Monday or Tuesday, but whatever. The problem? They didn't have the power supply, the 8600 and the dvd writer in stock. Worse, the dvd writer had an unknown delivery time. I don't understand why a shop doesn't pull the items from stock when an order is confirmed? What good is a stock quantity on the web site when they don't update it? I don't care what brand the dvd writer is, so I quickly send them an email and asked them to swap the writer for another one. It was the same price, so there wasn't any problem.

Another week passed, so I send them another mail. Apparently, the power supply also had an unknown delivery time. It was the only thing missing. I was kind of mad that they didn't tell me this before. But I decided to wait a little longer. The power supply was a popular brand so I thought it wouldn't take much time.

A few days later, they confirmed that the power supply would be in stock the beginning of June. I decided that I wouldn't take my chances and I've waited long enough. So I changed my order to a different power supply that was available. The new one was a little more expensive, so I'd have to do another wire transfer. They couldn't use my Visa for the order. I informed them that I don't want to pay for the power supply when someone else could still order it and it could be out of stock again before my money arrived. But they told me they'd take it out of stock and keep it for my order. Also, I didn't want to wait another week with the wire transfer before they install the power supply and ship the box. I hate waiting. But they didn't like that.

Apparently, they don't trust their customers to pay another $20 when they already paid $1400. I would understand this if it wasn't for the following: it's been almost 3 weeks, and everything is cheaper now. That means that I could cancel my current order, and order everything with the new power supply for the same amount! So a few mails went back and forth. They suggested a screenshot of the wire transfer confirmation would be ok. Of course, I made the transfer immediately and I couldn't do that anymore. So there is only one thing left to do: wait another week for the wire transfer, then probably another week for the shipment.

Do I like their tech support? No. Will I be ordering a second time from the same shop? No. Will I advise a colleague to buy his new PC at their shop? No. Did I learn a lesson about support? Yes.

New development box

I'm using a P4, 1Ghz, 512 MB RAM for development and testing. Not a bad system, and I can run Windows XP just fine. The problem is that I'm having trouble running VMware properly, and I certainly can't run Vista to test. So I was using my wife's laptop (A 2GB RAM dual core system) to test my applications. After a long time of agony and despair I finally gave in. It was time to put my old desktop to rest and buy a new system.

The new system looks like this:

• Intel Core 2 Duo E6600 (S775, 2x2.4GHz, 4MB, 1066MHz FSB, Boxed)
  
• Asus P5N-E SLI, nForce 650i (ATX, PCI-e, Sound, LAN, SATA II, RAID, 1394)
  
• Kingston 2GB DDR2 PC6400 800MHz CL5 HyperX Dual Channel Kit
  
• WD 74GB SATA 10000RPM 16MB Raptor
  
• XFX Geforce 8600 GTS 256MB DDR3
  

That should be enough for a long time (I hope). Now, the waiting game begins till the system arrives at my doorstep.

Finding crash information using the MAP file

This is an article previously published on the code project. It might be a little outdated, but it's still a good read.

Introduction

Programming neat applications is one thing. But when a user informs you your software has crashed, you know it's best to fix this before adding other features. If you're lucky enough, the user will have a crash address. This will go a long way in solving the problem. But how can you determine what went wrong, using this crash address?

Creating a MAP file

Well first of all, you'll need a MAP file. If you don't have one, it will be nearly impossible to find where your application crashed using the crash address. So first, I'll show you how to create a good MAP file. For this, I will create a new project (MAPFILE). You can do the same, or adjust your own project. I create a new project using the Win32 Application option in VC++ 6.0, selecting the 'typical "Hello Word!" application' to keep the size of the MAP file reasonable for explanation.

Once created we need to adjust the project settings for the release version. In the C/C++ tab, select "Line Numbers Only" for Debug Info.



Many people forget this, but you'll need this option if you want a good MAP file. This will not affect your release in any way. Next is the Link tab. Here you need to select the "Generate mapfile" option. Also, type the switches /MAPINFO:LINES and /MAPINFO:EXPORTS in the Project Options edit box.



Now, you're ready to compile and link your project. After linking, you will find a .map file in your intermediate directory (together with your exe).

Reading the MAP file

After all this dull work, now comes the neat part: how to read the MAP file. We'll do this by using a crash example. So first: how to crash your application. I did this by adding these two lines at the end of the InitInstance() function:

char* pEmpty = NULL;
*pEmpty = 'x'; // This is line 119

I'm sure you can find other instructions which will crash your application. Now recompile and link. If you start the application, it will crash and you'll get a message like this: 'The instruction at "0x004011a1" referenced memory at "0x00000000". The memory could not be "Written".' .

Now, it's time to open the MAP file with notepad or something similar. You MAP file will look like this:

The top of the MAP file contains the module name, the timestamp indicating the link of the project, and the preferred load address (which will probably be 0x00400000 unless you're using a dll). After the header comes the section information that shows which sections the linker brought in from the various OBJ and LIB files.

MAPFILE

Timestamp is 3df6394d (Tue Dec 10 19:58:21 2002)

Preferred load address is 00400000

Start Length Name Class
0001:00000000 000038feH .text CODE
0002:00000000 000000f4H .idata$5 DATA
0002:000000f8 00000394H .rdata DATA
0002:0000048c 00000028H .idata$2 DATA
0002:000004b4 00000014H .idata$3 DATA
0002:000004c8 000000f4H .idata$4 DATA
0002:000005bc 0000040aH .idata$6 DATA
0002:000009c6 00000000H .edata DATA
0003:00000000 00000004H .CRT$XCA DATA
0003:00000004 00000004H .CRT$XCZ DATA
0003:00000008 00000004H .CRT$XIA DATA
0003:0000000c 00000004H .CRT$XIC DATA
0003:00000010 00000004H .CRT$XIZ DATA
0003:00000014 00000004H .CRT$XPA DATA
0003:00000018 00000004H .CRT$XPZ DATA
0003:0000001c 00000004H .CRT$XTA DATA
0003:00000020 00000004H .CRT$XTZ DATA
0003:00000030 00002490H .data DATA
0003:000024c0 000005fcH .bss DATA
0004:00000000 00000250H .rsrc$01 DATA
0004:00000250 00000720H .rsrc$02 DATA

After the section information, you get the public function information. Notice the "public" part. If you have static-declared C functions, they won't show up in the MAP file. Fortunately, the line numbers will still reflect the static functions. The important parts of the public function information are the function names and the information in the Rva+Base column, which is the starting address of the function.

Address Publics by Value Rva+Base Lib:Object

0001:00000000 _WinMain@16 00401000 f MAPFILE.obj
0001:000000c0 ?MyRegisterClass@@YAGPAUHINSTANCE__@@@Z 004010c0 f MAPFILE.obj
0001:00000150 ?InitInstance@@YAHPAUHINSTANCE__@@H@Z 00401150 f MAPFILE.obj
0001:000001b0 ?WndProc@@YGJPAUHWND__@@IIJ@Z 004011b0 f MAPFILE.obj
0001:00000310 ?About@@YGJPAUHWND__@@IIJ@Z 00401310 f MAPFILE.obj
0001:00000350 _WinMainCRTStartup 00401350 f LIBC:wincrt0.obj
0001:00000446 __amsg_exit 00401446 f LIBC:wincrt0.obj
0001:0000048f __cinit 0040148f f LIBC:crt0dat.obj
0001:000004bc _exit 004014bc f LIBC:crt0dat.obj
0001:000004cd __exit 004014cd f LIBC:crt0dat.obj
0001:00000591 __XcptFilter 00401591 f LIBC:winxfltr.obj
0001:00000715 __wincmdln 00401715 f LIBC:wincmdln.obj
//SNIPPED FOR BETTER READING
0003:00002ab4 __FPinit 00408ab4
0003:00002ab8 __acmdln 00408ab8

entry point at 0001:00000350

Static symbols

0001:000035d0 LeadUp1 004045d0 f LIBC:memmove.obj
0001:000035fc LeadUp2 004045fc f LIBC:memmove.obj
//SNIPPED FOR BETTER READING
0001:00000577 __initterm 00401577 f LIBC:crt0dat.obj
0001:0000046b _fast_error_exit 0040146b f LIBC:wincrt0.obj

The public function part is followed by the line information (you got this if you used the /MAPINFO:LINES in the Link tab and selected the "Line numbers" in the C/C++ tab). After this, you will get the export information if your project contains exported functions and you included /MAPINFO:EXPORTS in the link tab.

Line numbers for .\Release\MAPFILE.obj(F:\MAPFILE\MAPFILE.cpp) segment .text

24 0001:00000000 30 0001:00000004 31 0001:0000001b 32 0001:00000027
35 0001:0000002d 53 0001:00000041 40 0001:00000047 43 0001:00000050
45 0001:00000077 47 0001:00000088 48 0001:0000008f 52 0001:000000ad
53 0001:000000b3 71 0001:000000c0 80 0001:000000c3 81 0001:000000c8
82 0001:000000ff 86 0001:00000114 88 0001:00000135 89 0001:00000145
102 0001:00000150 108 0001:00000155 110 0001:00000188 122 0001:0000018d
115 0001:0000018e 116 0001:0000019a 119 0001:000001a1 121 0001:000001a8
122 0001:000001ae 135 0001:000001b0 143 0001:000001cc 172 0001:000001ee
175 0001:0000020d 149 0001:00000216 157 0001:0000022c 175 0001:00000248
154 0001:00000251 174 0001:0000025f 175 0001:00000261 151 0001:0000026a
174 0001:00000287 175 0001:00000289 161 0001:00000294 164 0001:000002a8
165 0001:000002b6 166 0001:000002d8 174 0001:000002e7 175 0001:000002e9
169 0001:000002f2 174 0001:000002fa 175 0001:000002fc 179 0001:00000310
186 0001:0000031e 193 0001:0000032e 194 0001:00000330 188 0001:00000333
183 0001:00000344 194 0001:00000349

Now we will look up where the crash occurred. First, we'll determine which function contains the crash address. Look in the "Rva+Base" column and search the first function with an address bigger than the crash address. The preceding entry in the MAP file is the function that had the crash. In our example our crash address is 0x004011a1. This is between 0x00401150 and 0x004011b0 so we know the crash function is ?InitInstance@@YAHPAUHINSTANCE__@@H@Z . Any function name that starts with a question mark is a C++ decorated name. To translate the name, pass it as a command-line parameter to the Platform SDK program UNDNAME.EXE (in the bin dir). You won't need to do this most of the time as you might figure it out just by looking at it (here: InitInstance() in MAPFILE.obj).

This is a big step for bug tracking. But it gets even better: we can find out on which line the crash occurred! We need to do some basic hexadecimal mathematics, so people whom can't do this without a calculator: now is the time to use it. The first step is the following calculation: crash_address - preferred_load_address - 0x1000
Addresses are offsets from the beginning of the first code section, se we need to do this calculation. Subtracting the preferred load address is logical, but why do we need to substract another 0x1000? The crash address is an offset from the beginning of the code section, but the first part of the binary isn't the code section! The first part of the binary is the Portable Executable (PE), which is 0x1000 bytes long. Mystery solved. In our example, this is: 0x004011a1 - 0x00400000 - 0x1000 = 0x1a1

Now it's time to look in the line information section of the MAP file. The lines are shown like this: 30 0001:00000004. The first number is the line number, the second number is the offset from the beginning of the code section in which this line occurred. If we want to look for our line number, we just have to do the same thing we did for the function: determine the first occurrence of a bigger offset than the one we just calculated. The crash occurred in the preceding entry. In our example: 0x1a1 is before 0x1a8. So our crash occurred on line 119 in MAPFILE.CPP.

Keeping track of MAP files

Each release had it's own MAP file. It's not a bad idea to include the MAP file with the exe distribution. This way, you can be certain you have the correct MAP file for this exe. You could keep every MAP file with every exe on your system, but we all know this might give some troubles later on. The MAP file doesn't contain any information you wouldn't want the user to see (unless maybe class and function names ?) . A user would have no use with it, but at least you can ask for the MAP file if you don't have a copy yourself.

Welcome back, Commander.

Some of you know that I'm a gamer. Well, not actually a gamer, I just like to play games. I don't have the time to game more than a few hours a week. As a result, the Command & Conquer 3: Tiberium Wars game I preordered was still lying in my desk as I was finishing F.E.A.R.: Extraction Point (a game I recommend to anyone).



But I had some time off last weekend, and some of my friends coaxed me into playing C&C 3 online with them. I warned them that I haven't played it yet, and the last RTS game I played was Red Alert (so it was a while ago) but they just wouldn't take no for an answer. So I installed C&C3, ran the update, joined the game they created and got my ass handed to me after 10 minutes. Now I could justify this be telling you I didn't know the interface, which is partly true (e.g. I didn't know where I could build turrets). Worst of all you had to RIGHT CLICK to order your units to go somewhere or attack something. I was used to left clicking, so half of the time my units where standing there feeling rather bored while my base was under attack. But I think that there is also another reason: the game is extremely fast compared to older RTS games. And the options list is extremely big. Everything can be upgraded to extra features. It feels like you have to do a million things in a very short time. The learning curve is a lot steeper when you compare it to Red Alert. Or maybe I'm getting too old for this kind of thing? Anyway, it will take some time to get my skills to a decent level. And if I compare the time I need with the time I'm willing to spend in a week, then it will probably take me a few years.

Website facts

Some interesting facts from our website visitors:

• 60% use Internet Explorer, while 35% use Firefox. Firefox is still rising slightly, but not as fast as it did before.
  
• 80% use Windows XP, 7% use Vista. Windows 2000 and 2003 each take 5%. I'm surprised with how fast Vista is gaining popularity.
  
• Most people have a screen resolution of 1280x1024 or 1024x768 (each 35%). Only 5% have a resolution below 1024x768.
  
• 99% have java enabled
  

I am curious how many people have .net and which versions. Unfortunately, Google Analytics doesn't tell me.