problem on msmerge_genhistory

anyone that could help me resolve this problem?

Our replication failed when it was rebooted during replication. (by Helpdesk people).
Here are some details I have found on the problem.
ran DBCC CHECKTABLE ('msmerge_genhistory') gave following with these error msg.

Server: Msg 8927, Level 16, State 1, Line 2
Object ID 408440579, index ID 0: The ghosted record count (1) in the header does not match the number of ghosted records (0) found on page (1:4344).
Server: Msg 8928, Level 16, State 1, Line 2
Object ID 408440579, index ID 0: Page (1:4346) could not be processed. See other errors for details.
Server: Msg 8944, Level 16, State 1, Line 2
Table Corrupt: Object ID 408440579, index ID 0, page (1:4346), row 74. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 68 and 0.
Server: Msg 8928, Level 16, State 1, Line 2
Object ID 408440579, index ID 0: Page (1:92534) could not be processed. See other errors for details.
Server: Msg 8939, Level 16, State 1, Line 2
Table Corrupt: Object ID 408440579, index ID 0, page (1:92534). Test (m_freeCnt == freeCnt) failed. Values are 4967 and 4970.
Server: Msg 8928, Level 16, State 1, Line 2
Object ID 408440579, index ID 4: Page (1:11748) could not be processed. See other errors for details.
Server: Msg 8944, Level 16, State 1, Line 2
Table Corrupt: Object ID 408440579, index ID 4, page (1:11748), row 83. Test (ColumnOffsets <= (nextRec - pRec)) failed. Values are 33 and 0.
DBCC results for 'MSmerge_genhistory'.
There are 14755 rows in 349 pages for object 'MSmerge_genhistory'.
CHECKTABLE found 0 allocation errors and 7 consistency errors in table 'MSmerge_genhistory' (object ID 408440579).

select name from sysobjects where id = 408440579 returns MSmerge_genhistory

Tried dbcc with repair_allow_data_loss option and still corrupt table.

Any help is thankfull.Can you do a select from the table?

Whats the primary key?

Can you select a subset?

Can you select all of them (probably not)

Do you have a clean backup?

If you have 1 error, you might have many more...|||I could select from the user tables just the merging job is not going through at all.
it is a system table

Structure:

guidsrc uniqueidentifier
guidlocal uniqueidentifier
pubid uniqueidentifier Nullable
generation int
art_nick int
nicknames varbinary
coldate datetime.

The data inside do have duplicate even tho they are unique.
I can't run count on identifier columns.
SELECT DISTINCT *
FROM original_table
GROUP BY key_value
HAVING COUNT(key_value) > 1
Reason Cannot run count or aggrigate on uniqueidentifier.
Hope this helps.

Edit:
There are no good back up. I just started a month ago here. It is very badly structured environment.|||They set up replication but didn't worry about backups?

Is the subscriber or the publisher hosed?

Or both?|||here is sample data.

guidsrc: {C831F2CB-A997-485E-A5A4-000B1752CFD8}
guidlocal: {ACDD4DD8-998D-41B5-A138-44AAAA4F093B}
pubid: {FB7BFC63-7310-4F07-997C-01379C9346A9}generation 649835
art_nick: 6980021
nicknames: <Binary>
coldate:11/10/2003 5:05:32 PM

guidsrc: {D0D2EF6E-41DB-4F47-920B-00222B86D637}
guidlocal: {D0D2EF6E-41DB-4F47-920B-00222B86D637}
pubid: <NULL>
generation 631726
art_nick: 6980025
nicknames: <Binary>
coldate: 11/2/2003 3:00:22 PM

guidsrc: {B175F50B-3057-4867-9AD6-0026360EF2D6}
guidlocal: {E2D260C9-E9C5-4D48-BD27-8E99ABA8DEAF}
pubid: {FB7BFC63-7310-4F07-997C-01379C9346A9}
generation 634705
art_nick: 6980014
nicknames: <Binary>
coldate: 11/3/2003 8:00:44 PM

As you can see pubid duplicates and there are over 100 records with same pubid.

subscriber is the one with problem.
Thought about droping replication and recreating after fixing so we won't run into more problem. but MIS director is an accountant and not comfortable in doing this.|||Here is the environment.
Around 160 locations setup with merge to 15 regions. (Understandable since remote locations)

The rest all resides in HQ
15 regions setup to 7 collection regions.
15 regions merge with main publisher.
7 Collection regions merge with collection server.
Collection server merge with main publisher.

Is this crazy enough or what.
Edit: Forgot about account server that is merging with collection server.
State dedicated servers replicating in same manner to a seperate server. then that seperate server replicate to the main publisher in state dedicated db.