mismatched Mitsubishi

I have a Q series program where the function block internal auto assigned memory bits are mismatched. Reading from the PLC hasn't corrected. Is writing my individual program the answer? What's the worst that can happen? I have searched these bits and they do not appear to be used anywhere else in the PLC.

I didn't understand quite good your explanation of program, but I will try to help.
Q uses direct memory allocation, so for all non declared variables, compiler defines exact memory bits after building/rebuilding project. There are different software that can program Q (GxDeveloper, GX IEC Developer, GxWorks, etc) and they compile differently depending of type of software you are using and version you are using.
Now first thing that you have to do is upload application from PLC, device memory, and also configurations from PLC and eventual intelligent modules (if there are).
Then try to compile it. If everything is OK then you can start "playing".

First of all, what was it programmed in the first place, if it was GXIEC, GXWorks or GXDeveloper, if the first two, unless the original programmer downloaded the symbolic file then it cannot be re-produced as a structured project.
If done in GXDeveloper then uploading it should be ok, GXDeveloper uses the memory area as actual addresses, i.e. you put say D100 into an instruction then give it a symbol (note: unless the symbols or comments are downloaded then again you will not have any in an upload unless to the original source file).
In GXIEC & Works, you can just use symbolic addressing but unlike RW (AB) then these are not stored as a symbol but as actual addresses, only if the original programmer defined them as an actual address in the symbols.
When a variable is used without an actual address or as a parameter to a function block these are generated at compile time, only if the source code has not been compiled again will it match. Unfortunately this is because Mitsubishi has kept some sort of backward compatibility with the original GXDeveloper ladder only programming.
If you do upload the PLC to a new project then it can only be displayed in ladder or statement list, I do know that the older GXIEC could produce code that would create some errors i.e. un-connected ladder although it would work but not re-compile in GXDeveloper.

Thanks for the reply. I am using gxworks2 if that helps to clarify what steps to take.

Right, Assuming you do not have the original source file & the original programmer did not download the symbolic code to the PLC (Most don't for two reasons, 1. the symbolic code is too large & actual program so not enough memory or just did not bother). Then uploading it will only produce ladder & if they created some functions there will be a lot of higher addresses i.e. M9000 > & D9000 upwards.
There will also be a lot of jumps to subroutines after the FEND instruction (this is the end of the main scan).
If you do have the original source file & it was GXWorks then only if it has not been re-compiled will it be the same, however, if you are sure the source code you have is what is in the PLC then re-compiling it & downloading it will be ok.
You have not said if you have the original source code.
There are a number of possibilities, the code is not the same, it may be that the settings for the compiler (automatic assigned setting), if there are no errors in the actual code just the automatic assignment changed then re-compiling it & downloading will rectify it but only if you have the original source code. Without the symbolic code being downloaded the project cannot be re-constituted & only uploaded in ladder which will be a little hard to decipher due to the way it uses loads of sub routines.

I do not have the original source code. Ill try the auto assign setting tomorrow. Thanks for the info

It probably will not help you anyway, you can only upload the PLC code into ladder format anyway, there will probably be no comments.
Wat happens at compile time is the compiler will allocate certain bits/words as sort of temporary memories i.e. as local variables so for example
if I created a simple function block that took two variables to be passed to it and returned a sum of the two this is the sort of code it would do when compiled.

MOVE D100 D998 // Move first input variable to a temp
MOVE D101 D997 // ditto for second input variable
JC P1 // Jump to the pointer P1 (after the main program)
MOVE D996 D102 // on return from subroutine update the out parameter

FEND // this is the end of cyclic scan program

P1: ADD D998 D997 to D996 // add the two & store in the temp D996
RET

So you can see that the actual code produced uses these temps to do the function.
It means the function can be used many times with the one bit of code, this is only a simple example and produces more code than doing it longhand i.e. just doing the simple add, but most functions you build yourself will be far more complex & can be re-used many times saving time in typing.
If you call the same function many times within you program it jumps to the same bit of code just passes the variables.