UPDATE: Jeremy Thake has blogged about this and put up some code for a console application that shows internal names.

I was trying to get a content query web part to display a due date from a task and because the screen label is "Due Date", I assumed that the column name to use in <CommonViewFields> is "Due_x0020_Date".

Wrong!

The real column name in this case was "DueDate".

How did I find it?  I re-read Heather Solomon’s blog entry on modifying CQWP to show additional columns of data.  She describes this process at step #13.  Trust it.  It’s correct.  At least, it was correct for me.  I did not trust it at first for another column with a much longer name.

I say "Trust it" because I did not trust it and probably wasted near two hours butting my head up against a wall.  After I resolved the "DueDate" name, I wanted to add another field to <CommonViewFields>.  Using the Solomon technique, I was getting a column name like "XYZ_x0020_Project_x0020_Due_x00".

I thought to myself, that’s clearly a truncated name.  I went ahead and un-truncated it with no success.  I finally used the seemingly truncated name and it worked.

Bonus tip: When I was working with the CQWP, if I added a bad internal name to <CommonViewFields>, the CQWP would tell me that the query had returned no results.  But, if I added a data type to the field name, it would return a result.  Adding the data type actually masked a problem since I was referencing a non-existent field.  I could add it, but when I tried to display its value, I would always get a blank. 

This did not mask the error:

<CommonViewFields>Due_x0020_Date;</CommonViewfields>

This did mask the error:

<CommonViewFields>Due_x0020_Date,DateTime;</CommonViewfields>

</end>