New
#51
It does not look like a hardware issue, working on the assumption that the RAM sticks are assigned in the order they are listed by SMBios. If the assumption holds true, then the 4GB stick would be assigned to 0`00100000..1`000FFFFF and the 2GB stick would be at 1`00100000..1`800FFFFF. Looking at my current progress of isolating the issue (by hand), we have corruption at:
The last two rows of the table proper would be on the 4GB, versus the 2GB (working with the mentioned assumption). However, one can note that the low three bits of the address (either physical or virtual; the low 12 bits are always identical) are always 110b ≡ 0x6 or 0xe. This means that whatever is doing the spray is doing something like a `byte ptr [rax+6]` (where RAX is qword-aligned); I _might_ actually copy the most recent (6GB) memory dump to my Linux-based server box and write up a program which searches for any code which would refer to such a pointer. Maybe a smaller dump, actually, since driver code would be in the kernel memory area, right?Code:VIRTUAL ADDRESS P ADDRESS CHANGE fffff980`5603c6c6 = 1`197a66c6 : f1 -> ef fffff980`5603c6ce = 1`197a66ce : f1 -> ef fffff980`5603c6d6 = 1`197a66d6 : f1 -> ef fffff980`5603c6de = 1`197a66de : f1 -> ef fffff980`5603c6e6 = 1`197a66e6 : f1 -> ef fffff980`5603c6ee = 1`197a66ee : f1 -> ef fffff980`5603c6f6 = 1`197a66f6 : f1 -> ef fffff980`5603c6fe = 1`197a66fe : f1 -> ef fffff8a0`10fade6e = 1`1b73fe6e : ff -> 38 fffff8a0`10fade76 = 1`1b73fe76 : ff -> 05 fffff8a0`095bfe26 = 0`b73aae26 : ff -> 0c fffff8a0`095bfe36 = 0`b73aae36 : ff -> 04
EDIT: Current physical address mask is 0_1___10_11_01___1___1______110b; I expect the higher bits to disappear as I do more analysis
EDIT: It simplifies to 110b, so it is almost certain that it is, in fact, spray from SOMEthing.
Last edited by TruePikachu; 27 Aug 2015 at 16:20.