There are various types of software that like to inject code into every running process. Some of them, like Team Viewer, anti-virus programs and other malware may modify modules loaded by the victim process in order to hook certain system functions. This is one possible explanation.
Another explanation might be simple relocation, when a module cannot be loaded at its preferred base address because the address range would overlap memory already in use (e.g. dynamically allocated or occupied by another module). Hence a modification of DLL load order can result in certain modules sometimes getting relocated and sometimes not. The DLL injection mentioned in the first paragraph is one of the possible causes.
In the light of your comment: just looking at the two partial hex dumps makes it impossibly difficult to tell whether the corruption is meaningful/purposeful - like caused by some piece of software with a specific goal in mind - or random.
Even apparently random corruption could be the result of purpose, like some malware trying to get traction by heap spraying, stack smashing or similar. Or it could be the result of a malfunctioning module, like a JPEG library stumbling over an ill-formed picture.
And don't forget hardware failure... We've had memory fail with sporadic bit flips when running stressy programs during a heat wave. Similar things might happen when memory bars heat up under high load, or when the power supply gets overstressed and the quality of its output starts to suffer.
Sorry, without more data to go on there's little one can offer apart from guesswork.
There are, however, some things that you can investigate yourself since you have full control over the program. The corrupted dumps you've shown - code and relocation table - belong to sections that are normally not writeable. If you can ascertain that the affected sections are indeed read-only - for example via VirtualQuery() - then the hypothesis of malfunctioning normal code within your program can be excluded, leaving only malware, malfunctioning god-mode code (drivers) and hardware failure.
Note: VMMap allows visual inspection of the memory of a running process, without the need to write code using VirtualQuery().
Under Windows 95 & Co. there was a peculiar problem because the kernel 'recycled' mapped images of executables in the address spaces of other processes without employing copy-on-write when one of those mappings was modified (meaning the change was visible in all other processes as well).
But that shouldn't happen in the line of Windowzen descended from NT, i.e. from Windows 2000 onwards (yes, we still have one of those running because of a peculiar interface card for expensive custom hardware). I mentioned the problem only because it is an example of how normal code doing normal things could defeat the write-protection of the corrupted segments without even meaning to.
If the corrupted sections are not write-protected then you should investigate why and fix the problem. If all else fails, use VirtualProtect(). Should normal code accidentally try to write to the protected segments then this would cause a fault and termination of the program, and a procdump started for this purpose could take a snapshot (mini dump) of the program at the moment of the fault.
