All we can really say is that there is some kind of problem with the mappings when you see the 'Data rows with unmapped dimensions' error. When you're seeing this error it often means that one or more of the the UD? columns (where ? is an integer) has not been mapped to a corresponding UD?X column in the TDATASEG table (the mappings populate the UD?X columns).
You may be able to see which dimensions have problems by looking at the data load workbench and choosing 'show all data'. That will show invalid rows of data and might let you identify the problematic dimensions (ones with no dimension mappings for some reason). That's not always sufficient to see why the mappings are failing though.
If the data load workbench doesn't help then you'll need to get a process details log from FDMEE at log level 5 (log level is set via the FDMEE admin or user settings) where you will be able to see the logic of how the mappings are marked as invalid in the SQL that is run (log level 5 includes most of the SQL that is run for debugging purposes). You have a query something like the below that runs after the data has been loaded into the FDMEE staging tables and the mappings have all been done that will mark rows as invalid if mappings aren't present. If VALID_FLAG is set to N then the row has been marked as invalid
UPDATE TDATASEG SET VALID_FLAG = 'N' WHERE 1=1 AND ( (1=0) OR (TDATASEG.ACCOUNTX IS NULL OR TDATASEG.ACCOUNTX = '') OR (TDATASEG.ENTITYX IS NULL OR TDATASEG.ENTITYX = '') OR (TDATASEG.UD1X IS NULL OR TDATASEG.UD1X = '') )
If you can't resolve from the data load workbench then I'd say get a process details log in log level 5 and work through the mappings in the 'Processing Mappings for Column' sections. You should hopefully be able to identify which mapping is not working as expected. The mapping name is given below the SQL that carried out the mapping in something like this so that can let you hone in on problematic mapping rules:
2014-03-11 14:51:29,181 INFO [AIF]: Data Rows Updated by Rule Mapping 'Ver1' (LIKE): 18