Some question about exclusive OR

[197]

TRAP_FRAME:  ffffba00dff02450 -- (.trap 0xffffba00dff02450)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000a7b0003c rbx=0000000000000000 rcx=000000009bab0db0
rdx=000000000e721c4e rsi=0000000000000000 rdi=0000000000000000
rip=fffff8019c099c25 rsp=ffffba00dff025e8 rbp=000000006f1f486b
 r8=2858000000000000  r9=ffffffff8816fd30 r10=00000000ac3813af
r11=fffff8019bfd3bd2 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
BEDaisy+0x499c25:
fffff801`9c099c25 443194047effff87 xor     dword ptr [rsp+rax-78000082h],r10d ss:0018:ffffba01`0fa025a2=????????
Resetting default scope

4: kd> .formats ffffba01`0fa025a2
Evaluate expression:
  Hex:     ffffba01`0fa025a2
  Decimal: -76961256823390
  Octal:   1777775640041750022642
  Binary:  11111111 11111111 10111010 00000001 00001111 10100000 00100101 10100010
  Chars:   ......%.
  Time:    ***** Invalid FILETIME
  Float:   low 1.57917e-029 high -1.#QNAN
  Double:  -1.#QNAN

4: kd> .formats 0fa025a2
Evaluate expression:
  Hex:     00000000`0fa025a2
  Decimal: 262153634
  Octal:   0000000000001750022642
  Binary:  00000000 00000000 00000000 00000000 00001111 10100000 00100101 10100010
  Chars:   ......%.
  Time:    Sun Apr 23 07:27:14 1978
  Float:   low 1.57917e-029 high 0
  Double:  1.29521e-315

What is the .formats value we need to look at here? Also, how can we interpret the relationship between XOR and these canonical or non-canonical memory regions?

 

[RichLan564]

Um, a bit random, are you sure you are in the right forum?

Looking at your posting history i think you need to learn the correct way of asking a question especially a technical one, hint, your post isn't the correct way

 

[SpyderTracks]

TRAP_FRAME:  ffffba00dff02450 -- (.trap 0xffffba00dff02450)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000a7b0003c rbx=0000000000000000 rcx=000000009bab0db0
rdx=000000000e721c4e rsi=0000000000000000 rdi=0000000000000000
rip=fffff8019c099c25 rsp=ffffba00dff025e8 rbp=000000006f1f486b
 r8=2858000000000000  r9=ffffffff8816fd30 r10=00000000ac3813af
r11=fffff8019bfd3bd2 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
BEDaisy+0x499c25:
fffff801`9c099c25 443194047effff87 xor     dword ptr [rsp+rax-78000082h],r10d ss:0018:ffffba01`0fa025a2=????????
Resetting default scope

4: kd> .formats ffffba01`0fa025a2
Evaluate expression:
  Hex:     ffffba01`0fa025a2
  Decimal: -76961256823390
  Octal:   1777775640041750022642
  Binary:  11111111 11111111 10111010 00000001 00001111 10100000 00100101 10100010
  Chars:   ......%.
  Time:    ***** Invalid FILETIME
  Float:   low 1.57917e-029 high -1.#QNAN
  Double:  -1.#QNAN

4: kd> .formats 0fa025a2
Evaluate expression:
  Hex:     00000000`0fa025a2
  Decimal: 262153634
  Octal:   0000000000001750022642
  Binary:  00000000 00000000 00000000 00000000 00001111 10100000 00100101 10100010
  Chars:   ......%.
  Time:    Sun Apr 23 07:27:14 1978
  Float:   low 1.57917e-029 high 0
  Double:  1.29521e-315

What is the .formats value we need to look at here? Also, how can we interpret the relationship between XOR and these canonical or non-canonical memory regions?

You may be needing a different forum, this forum is for support on PCSpecialist systems. PCS are an OEM hardware integrator.

 

[ubuysa]

Since this isn't a question seeking help on a non-PCS build but a general question I'm happy to answer it.

The instruction that failed (at BEDaisy+0x499c25) was an XOR instruction as you noted. It does a bitwise exclusive OR on the lower 8 bits of Register 10 (R10d) and the lower 8 bits of the memory location pointed to by the sum of the RSP register and the RAX register minus 0x78000082. The problem is that the result of that memory pointer is an invalid memory location (0xffffba01`0fa025a2) as indicated by the ????????.

That it's an XOR instruction is irrelevant here, the problem is the invalid memory reference. We have no way to establish why BEDaisy.sys made this invalid memory reference because we have no symbols for BEDaisy.sys and so cannot debug it. The best we can do in this situation is flag BEDaisy.sys as the likely cause of this BSOD (it's the cause of many BSODs and is a well-known problem driver).

I don't know why you used the .formats command nor what you're trying to show there? The address that was referenced is canonical, it begins with 0xFFFF (so it's in the kernel memory space), it's just not a valid memory location; it's either not allocated, paged out, the RAM backing that page is bad, or (more likely) the driver has fouled up the pointer calculation.

Dump analysis is most usually not an exact science. We can generally point to what failed but explaining why it failed is often not possible - because all the code (Microsoft and third party) is proprietary and we have no detailed symbol files for any of this code.

 

[197]

Since this isn't a question seeking help on a non-PCS build but a general question I'm happy to answer it.

The instruction that failed (at BEDaisy+0x499c25) was an XOR instruction as you noted. It does a bitwise exclusive OR on the lower 8 bits of Register 10 (R10d) and the lower 8 bits of the memory location pointed to by the sum of the RSP register and the RAX register minus 0x78000082. The problem is that the result of that memory pointer is an invalid memory location (0xffffba01`0fa025a2) as indicated by the ????????.

That it's an XOR instruction is irrelevant here, the problem is the invalid memory reference. We have no way to establish why BEDaisy.sys made this invalid memory reference because we have no symbols for BEDaisy.sys and so cannot debug it. The best we can do in this situation is flag BEDaisy.sys as the likely cause of this BSOD (it's the cause of many BSODs and is a well-known problem driver).

I don't know why you used the .formats command nor what you're trying to show there? The address that was referenced is canonical, it begins with 0xFFFF (so it's in the kernel memory space), it's just not a valid memory location; it's either not allocated, paged out, the RAM backing that page is bad, or (more likely) the driver has fouled up the pointer calculation.

Dump analysis is most usually not an exact science. We can generally point to what failed but explaining why it failed is often not possible - because all the code (Microsoft and third party) is proprietary and we have no detailed symbol files for any of this code.

Thanks for the answer. I don't know what relationship I made between XOR and .formats, I may have tried to look for a relationship because of the similarity of 1 if true and 0 if false that I remembered from math. Your answer was enough.