Sorry to make you wait for me sladlejrhfpq, I will show you how does SR_GameServer or SR_ShardManager read the Database line by line ... To mention, I didn't catch all columns exactly by using this method ... but I can give you a clue how I did to find "How Server files read Database Data" using ollydbg ...
Notes:
First, the problem with overlap cannot be solved easily only if you want to know what does make it going to that stage.
Second, ollydbg registers always have dumped for what happen before it goes to exception stage.
Finally, try and guess must be always your method to explore!!
Let's begin,,
When I was refilling Tables after delete them from the database, I was getting overlap when I insert data in the tables (You know, _RefObjCommon, _RefObjChar, _RefObjItem, ... etc) So I decided to debug execution of SR_ShardManager ...
I fill all tables with the data and started to run SR_ShardManager using Ollydbg ... When the exception happens ... The debugger stops at the line that cause this exception and pause the processing of SR_ShardManager ... Like this one :
Screenshot by Lightshot
The Instruction stopped at LEAVE command ... That means there is something wrong that SR_ShardManager can't process it due of unknown problem ...
At this stage, lets check what does memory contain from this processing by checking this one inside ollydbg:
Screenshot by Lightshot
The black line is what to insert data or whatever you can call it from saving temporary data ... Above the black line are the dump data and under the black line is something related with handlers, resources, methods, or whatever that still active ...
At this stage, reading what inside memory dumps is our goal to define where is the problem stopped ... But what things I should look for??
Simple, You have to look on all ASCII dumps that might be related on inside SR_ShardManager or dumps from what SR_ShardManager retrieved from the database ...
You need to scroll up to see what is inside memory ... The nearest to the black line, the most recent data used before it goes to exception stage, Look what I have found:
Screenshot by Lightshot
The ASCII "xxx" might be useful somehow ... But we should know that It might be retrieved from a database or it was inside SR_ShardManager ...
Other things I found:
Screenshot by Lightshot
Code:
This is China Man Advanture Character BSR location, I think it is retrieved from the database ...
Screenshot by Lightshot
Code:
This is China Man Advanture Character Codename, but I don't know which column it is exactly retrieved from the database ...
Screenshot by Lightshot
Code:
This is necklace item degree 9 ... I think it was the last Item the SR_ShardManager read it successfully ... Of course it will read it successfully after I edit the _RefObjItem structure ...
Still didn't get why It stopped on reading CHAR_CH_MAN_ADVANTURE ... But at least, I know that it stopped on reading at the CHAR_CH_MAN_ADVANTURE line ...
I want to be more sure about that one ... Can't imagine how it stopped at this line ... I want to see it stopping while I'm using my eyes ... !!
The solution is set a breakpoints on offsets that was processed in that stage ... This is optional point since I know the error from only reading the dumps, But which offsets I should set breakpoints ?
Remember the ASCII "xxx" ?? It can be a clue to my problem ... What I have to do now is to search for All ASCII "xxx" on SR_ShardManager ... And set on all of them breakpoint ... Look how I will do it:
Restart your application by click this button "<<"
Screenshot by Lightshot
Right click on CPU area, and choose from "Search for" option "All referenced text string"
Screenshot by Lightshot
Go to the top of the list, select the top line, Right click, then choose "Search for", remove tick from case sensitive and write in the box xxx and click search:
Screenshot by Lightshot
Screenshot by Lightshot
When you found one of them, press F2 to set the breakpoint that will highlight the offset with red ... Do it for all ASCII strings that has xxx ...
To check all your breakpoints you made it, click on the "B" icon to show you the list:
Screenshot by Lightshot
Lets back to the problem, I want to see what all these break points do when the process goes there ... Click on "C" icon to show you the CPU window:
Screenshot by Lightshot
Let's run the SR_ShardManager ... (Of course you need to run other nodes like Cert, Global, Farm, ...etc) ...
While it is loading ... You will see that SR_ShardManager freeze and the windows focus back to the debugger ... Also, you will see that black line of the CPU windows is selecting your breakpoint
Screenshot by Lightshot
I have put red lines on windows, the windows I have select it is the registers window (FPU), Where EAX, EBX, ECX, EDX, .... and other registers are displayed there ...
To skip to the next breakpoint, you have to press F9 each time you want to skip ... Remember to remove break points if you see them not necessary to put them by pressing F2 on the line ...
DON'T FORGET TO MONITOR THE registers window (FPU), look what I have found while I was skipping break points ...
Screenshot by Lightshot
That break point is the most important to me to know what line I'm at the moment ... So I canceled all other break points that made the processor go slower ...
Keep pressing F9 to see that register updating with the lines ...
Screenshot by Lightshot
Until you see that you have reached at line that you can't move or skip using F9 (LEAVE or anything else) ...
Screenshot by Lightshot
Lol, do you remember what was last ASCII you skip it ?? If you don't ... You have to do the whole setup again and check what was the last ASCII you skipped at the break point ... And that ASCII is your problem ... That is all ...
Don't know if this is helpful .. But might be useful ...