Solved [ HELP ] "Access violation reading location" error when trying to call in-game function.

Hexui Undetected CSGO Cheats PUBG Accounts

mermaid

Full Member
Jan 16, 2021
5
104
0
Game Name
Europa Universalis IV
Anticheat
None
Tutorial Link
N/A
How long you been coding/hacking?
3 years
Coding Language
C++
Context
The objective here is to call a function that moves the selected army to a specific province. Upon analysing the source code in IDA I have come across this patch of code that should do what I'm trying to accomplish. Through further analysis I came to the conclusion that the variable v43 stores the address to the target province object. The function I'm trying to call here is f_MoveArmy((v7 + 0x28), v43, v44);. I know that the first argument always points to the currently selected army, the second argument points to the province object that is going to be used to determine where the currently selected army should move to and the last argument is a boolean that indicates if the path should be appended to the current path or create a new one. So far so good.

C++:
v43 = f_FetchProvinceID(v40, *(v42 + 2 * a2));
                    if ( v43 )
                    {
                      if ( sub_7FF684741D90(v7) )
                      {
                        v44 = (*(*v6 + 0x38i64))(v6);// Function for deciding whether to
                                                // append to current path or create new one
                        f_MoveArmy((v7 + 0x28), v43, v44);
                      }
                      else if ( !*(qword_7FF685B06A10 + 304) && *(v43 + 1056) >> 56 )
                      {
                        _mm_storeu_si128(&v69, 0i64);
If You happen to have the game, then you can test this out with the files I've uploaded on my GitHub. I'll be pasting code snippets anyways.
The implementation of previously mentioned is as follows:
C++:
            CWorld* pWorld = (CWorld*)(BASE + 0x223D380);

            DEBUG("[INFO] Fetching province object for province with ID: 1753\n");
            uintptr_t *pProvince = tFetchProvinceID(BASE + 0xed0d0)(pWorld->pMap->pProvinces->pSelection->pNotSure1->pNotSure2->pNotSure3->pAdjacancies, 1753);
            DEBUG("[INFO] Fetched province object = %p\n", (void*)pProvince);

            DEBUG("[INFO] Moving currently selected army\n");
           
            uintptr_t *currentArmy = (uintptr_t*)((uintptr_t) pWorld->pMap->pProvinces->pSelection + 0x28);
            DEBUG("[INFO] Current army selected: %p\n", (void*) currentArmy);
            tMoveArmy(BASE + 0xe7f4bb)(currentArmy, pProvince, 0);

            DEBUG("[INFO] Army en route\n");
To control that what I have implemented is correct I have put a breakpoint on f_MoveArmy((v7 + 0x28), v43, v44) and compared it to my arguments to see that I'm properly matching the game. No issue there. The only thing that could be iffy is the calling convention, but my assumption is that most x64 functions use fastcall as the calling convention. Feel free to comment on this.



ISSUE​
Exception thrown at 0x00007FF683E00F00 in eu4.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
The error is referring to the following line: 7FF683E00F00 - 0F29 74 24 30 - movaps [rsp+30], xmm6. What I've noticed is that whenever the game executes this line the register always looks like this:
40733B9D0DA7886F
whereas when f_MoveArmy((v7 + 0x28), v43, v44) is ran by me it looks like this
000000004200AB5D
. I've also changed the XMM6 register to different values both when that line is executed by the game and me, and there's no difference. If the game executes that line then no matter what result resides inside XMM6 it will always go through. When f_MoveArmy((v7 + 0x28), v43, v44) is being executed by the game then that XMM6 register value is already there BEFORE it runs the function. This makes me wonder if I should climb the stack a couple of levels so that when I execute that function it would set the XMM6 as well as run f_MoveArmy((v7 + 0x28), v43, v44) .

Few things to keep in mind, this error occurs several layers inside f_MoveArmy((v7 + 0x28), v43, v44) and not in the function itself.
C++:
__int64 v44; // [rsp+98h] [rbp-68h]
  __int64 v45; // [rsp+A0h] [rbp-60h]
  char v46; // [rsp+B0h] [rbp-50h]
  char *v47; // [rsp+E8h] [rbp-18h]
  __int64 v48; // [rsp+F0h] [rbp-10h]
  __int64 v49; // [rsp+130h] [rbp+30h]

  v48 = -2i64;
  v3 = a3;
  v4 = a2;
  v5 = 0;
  v44 = 0i64;
  v45 = 0i64;
  v43 = &off_7FF685309220;
  v6 = *a1;
  if ( *a1 )
  {
    do
    {
      v7 = *v6;
      if ( (*(**v6 + 0x38i64))(*v6, &v43, v4, v3) )
      {
        v5 |= (*(*v7 + 0x30i64))(v7, v4, v3);
        v8 = HIDWORD(v45);
      }
      else
      {
        v8 = HIDWORD(v45);
        v5 = HIDWORD(v45) != 0;
      }
      v6 = v6[2];
    }
    while ( v6 );
    if ( v8 == 1 )
This is a code patch taken from IDA in the f_MoveArmy((v7 + 0x28), v43, v44) function. The line v5 |= (*(*v7 + 0x30i64))(v7, v4, v3) is where it crashes. We go deeper.
C++:
               if ( dword_7FF685C2DD00 == -1 )
                {
                  sub_7FF6839A8CF0(&qword_7FF685AE41C0, "army_move", 9ui64);
                  atexit(sub_7FF685143AA0);
                  Init_thread_footer(&dword_7FF685C2DD00);
                }
              }
              if ( qword_7FF685AE41D8 >= 0x10 )
                v86 = qword_7FF685AE41C0;
            }
LABEL_258:
            v95 = sub_7FF684BEE840(**(qword_7FF685AFD668 + 840), v86, 1);
            f_AudioOnMarch(v95, v96, 1.0);
            return v144;
          }
A code patch from the current function. The line f_AudioOnMarch(v95, v96, 1.0) is where it crashes.
Assembly of it:
7FF683E00EF0 - 40 53 - push rbx
7FF683E00EF2 - 48 83 EC 40 - sub rsp,40
7FF683E00EF6 - 48 8B 05 6BC7CF01 - mov rax,[7FF685AFD668]
7FF683E00EFD - 48 8B D9 - mov rbx,rcx
7FF683E00F00 - 0F29 74 24 30 - movaps [rsp+30],xmm6
7FF683E00F05 - 48 8B D3 - mov rdx,rbx
7FF683E00F08 - 0F28 F2 - movaps xmm6,xmm2
7FF683E00F0B - 48 8B 88 48030000 - mov rcx,[rax+00000348]
7FF683E00F12 - 48 8B 09 - mov rcx,[rcx]
7FF683E00F15 - E8 A6DDDE00 - call 7FF684BEECC0
7FF683E00F1A - 48 8B 05 47C7CF01 - mov rax,[7FF685AFD668]
7FF683E00F21 - 0F57 C0 - xorps xmm0,xmm0
7FF683E00F24 - 0F28 DE - movaps xmm3,xmm6
7FF683E00F27 - F3 0F11 44 24 20 - movss [rsp+20],xmm0
7FF683E00F2D - 45 33 C0 - xor r8d,r8d
7FF683E00F30 - 48 8B 90 48030000 - mov rdx,[rax+00000348]
7FF683E00F37 - 48 8B 0A - mov rcx,[rdx]
7FF683E00F3A - 48 8B D3 - mov rdx,rbx
7FF683E00F3D - E8 CE1EDF00 - call 7FF684BF2E10
7FF683E00F42 - 0F28 74 24 30 - movaps xmm6,[rsp+30]
7FF683E00F47 - 48 83 C4 40 - add rsp,40
With all this being said, any help would be appreciated, thanks!
 
Last edited:
  • Like
Reactions: Kleon742

Kleon742

Feature Enthusiast
Dank Tier VIP
Dank Tier Donator
Sep 2, 2018
381
17,058
45
Hey there, so, great post first of all. Finally someone who's actually doing some game hacking without pasting, thank god. Love how much info you provided, exactly what's needed, fucken hell why can't people post like this all the time...
Anyways.
So It's a long ass post and I just woke up but:
Exception thrown at 0x00007FF683E00F00 in eu4.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
Is a GP exception, the best of way of going with problems like this is taking a look at what's causing it.
The error is referring to the following line: 7FF683E00F00 - 0F29 74 24 30 - movaps [rsp+30], xmm6.
Great, now let's take a look at the movaps documentation.
As you can see, there are a few ways to trigger an exception:
1610880515957.png

and the most common one is to not align the operand on a 16-byte boundary.

What you just said here:
What I've noticed is that whenever the game executes this line the register always looks like this:
40733B9D0DA7886F
whereas when f_MoveArmy((v7 + 0x28), v43, v44) is ran by me it looks like this
000000004200AB5D
This is mostlikely the problem, it looks like an alignment issue. You might be calling the function with incorrect number of params most likely, but search for stack miss-alignment problems anyways.

Hope it helps. Keep us updated.
 
Last edited:

DoUknowme

Full Member
Nobleman
Nov 24, 2018
113
598
1
Context
The objective here is to call a function that moves the selected army to a specific province. Upon analysing the source code in IDA I have come across this patch of code that should do what I'm trying to accomplish. Through further analysis I came to the conclusion that the variable v43 stores the address to the target province object. The function I'm trying to call here is f_MoveArmy((v7 + 0x28), v43, v44);. I know that the first argument always points to the currently selected army, the second argument points to the province object that is going to be used to determine where the currently selected army should move to and the last argument is a boolean that indicates if the path should be appended to the current path or create a new one. So far so good.

C++:
v43 = f_FetchProvinceID(v40, *(v42 + 2 * a2));
                    if ( v43 )
                    {
                      if ( sub_7FF684741D90(v7) )
                      {
                        v44 = (*(*v6 + 0x38i64))(v6);// Function for deciding whether to
                                                // append to current path or create new one
                        f_MoveArmy((v7 + 0x28), v43, v44);
                      }
                      else if ( !*(qword_7FF685B06A10 + 304) && *(v43 + 1056) >> 56 )
                      {
                        _mm_storeu_si128(&v69, 0i64);
If You happen to have the game, then you can test this out with the files I've uploaded on my GitHub. I'll be pasting code snippets anyways.
The implementation of previously mentioned is as follows:
C++:
            CWorld* pWorld = (CWorld*)(BASE + 0x223D380);

            DEBUG("[INFO] Fetching province object for province with ID: 1753\n");
            uintptr_t *pProvince = tFetchProvinceID(BASE + 0xed0d0)(pWorld->pMap->pProvinces->pSelection->pNotSure1->pNotSure2->pNotSure3->pAdjacancies, 1753);
            DEBUG("[INFO] Fetched province object = %p\n", (void*)pProvince);

            DEBUG("[INFO] Moving currently selected army\n");
          
            uintptr_t *currentArmy = (uintptr_t*)((uintptr_t) pWorld->pMap->pProvinces->pSelection + 0x28);
            DEBUG("[INFO] Current army selected: %p\n", (void*) currentArmy);
            tMoveArmy(BASE + 0xe7f4bb)(currentArmy, pProvince, 0);

            DEBUG("[INFO] Army en route\n");
To control that what I have implemented is correct I have put a breakpoint on f_MoveArmy((v7 + 0x28), v43, v44) and compared it to my arguments to see that I'm properly matching the game. No issue there. The only thing that could be iffy is the calling convention, but my assumption is that most x64 functions use fastcall as the calling convention. Feel free to comment on this.



ISSUE​


The error is referring to the following line: 7FF683E00F00 - 0F29 74 24 30 - movaps [rsp+30], xmm6. What I've noticed is that whenever the game executes this line the register always looks like this: whereas when f_MoveArmy((v7 + 0x28), v43, v44) is ran by me it looks like this . I've also changed the XMM6 register to different values both when that line is executed by the game and me, and there's no difference. If the game executes that line then no matter what result resides inside XMM6 it will always go through. When f_MoveArmy((v7 + 0x28), v43, v44) is being executed by the game then that XMM6 register value is already there BEFORE it runs the function. This makes me wonder if I should climb the stack a couple of levels so that when I execute that function it would set the XMM6 as well as run f_MoveArmy((v7 + 0x28), v43, v44) .

Few things to keep in mind, this error occurs several layers inside f_MoveArmy((v7 + 0x28), v43, v44) and not in the function itself.
C++:
__int64 v44; // [rsp+98h] [rbp-68h]
  __int64 v45; // [rsp+A0h] [rbp-60h]
  char v46; // [rsp+B0h] [rbp-50h]
  char *v47; // [rsp+E8h] [rbp-18h]
  __int64 v48; // [rsp+F0h] [rbp-10h]
  __int64 v49; // [rsp+130h] [rbp+30h]

  v48 = -2i64;
  v3 = a3;
  v4 = a2;
  v5 = 0;
  v44 = 0i64;
  v45 = 0i64;
  v43 = &off_7FF685309220;
  v6 = *a1;
  if ( *a1 )
  {
    do
    {
      v7 = *v6;
      if ( (*(**v6 + 0x38i64))(*v6, &v43, v4, v3) )
      {
        v5 |= (*(*v7 + 0x30i64))(v7, v4, v3);
        v8 = HIDWORD(v45);
      }
      else
      {
        v8 = HIDWORD(v45);
        v5 = HIDWORD(v45) != 0;
      }
      v6 = v6[2];
    }
    while ( v6 );
    if ( v8 == 1 )
This is a code patch taken from IDA in the f_MoveArmy((v7 + 0x28), v43, v44) function. The line v5 |= (*(*v7 + 0x30i64))(v7, v4, v3) is where it crashes. We go deeper.
C++:
               if ( dword_7FF685C2DD00 == -1 )
                {
                  sub_7FF6839A8CF0(&qword_7FF685AE41C0, "army_move", 9ui64);
                  atexit(sub_7FF685143AA0);
                  Init_thread_footer(&dword_7FF685C2DD00);
                }
              }
              if ( qword_7FF685AE41D8 >= 0x10 )
                v86 = qword_7FF685AE41C0;
            }
LABEL_258:
            v95 = sub_7FF684BEE840(**(qword_7FF685AFD668 + 840), v86, 1);
            f_AudioOnMarch(v95, v96, 1.0);
            return v144;
          }
A code patch from the current function. The line f_AudioOnMarch(v95, v96, 1.0) is where it crashes.
Assembly of it:


With all this being said, any help would be appreciated, thanks!
If the line where it crashes is really movaps [rsp+30],xmm6 then the value of xmm6 doesn't matter(at least it is not the primary reason) considering that the game just preserves the contents of xmm6 to the stack and restores its contents near the end of the function (see movaps xmm6,[rsp+30]).

If the game cannot access the location at [rsp+30] then it means that your stack is messed up.

P.S: didn't see the first reply, forgot about the alignment, lol.
 
Last edited:

mermaid

Full Member
Jan 16, 2021
5
104
0
Hey there, so, great post first of all. Finally someone who's actually doing some game hacking without pasting, thank god. Love how much info you provided, exactly what's needed, fucken hell why can't people post like this all the time...
Anyways.
So It's a long ass post and I just woke up but:

Is a GP exception, the best of way of going with problems like this is taking a look at what's causing it.


Great, now let's take a look at the movaps documentation.
As you can see, there are a few ways to trigger an exception:
1610880515957.png
and the most common one is to not align the operand on a 16-byte boundary.

What you just said here:

This is mostlikely the problem, it looks like an alignment issue. You might be calling the function with incorrect number of params most likely, but search for stack miss-alignment problems anyways.

Hope it helps. Keep us updated.
Will do! I put some time writing this so updating this as I go along would only be the right thing. I will take what you said and dig deeper with stack miss-alignment. Just out of curiosity sake I tried NOPing the call to the function where the exception occurs and it would run just fine when the function gets called by the game. However, it would eventually crash giving the same error which is making me suspect it has to do with stack miss-alignment.
 

mermaid

Full Member
Jan 16, 2021
5
104
0
Read the rules
UPDATE:
I've checked out the parameters just in case the problem was that simple, but It seems that the function, as previously mentioned, has exactly three parameters. I've checked corss-references to f_MoveArmy and the assembly looks fairly similiar.

This is the assembly from the first code patch:
7FF6B202F4AD - FF 52 38 - call qword ptr [rdx+38]
7FF6B202F4B0 - 44 0FB6 C0 - movzx r8d,al
7FF6B202F4B4 - 48 8D 4F 28 - lea rcx,[rdi+28]
7FF6B202F4B8 - 48 8B D6 - mov rdx,rsi
7FF6B202F4BB - E8 C027ADFF - call 7FF6B1B01C80
And this is from another cross-reference
7FF6B202E68E - 74 35 - je 7FF6B202E6C5
7FF6B202E690 - 8B 58 20 - mov ebx,[rax+20]
7FF6B202E693 - 48 8D 4F 28 - lea rcx,[rdi+28]
7FF6B202E697 - 45 33 C0 - xor r8d,r8d
7FF6B202E69A - 48 8B D0 - mov rdx,rax
7FF6B202E69D - E8 DE35ADFF - call 7FF6B1B01C80
After observing this, I was about 95% sure that there are only three parameters to this function. Now, to bump that to 99% I put breakpoint on the function call and set R9, R9, R10, R11 as well as all XMM registers to 0. The game didn't crash. Hmmm. I don't think the issue lies with incorrect number of parameters.
 
Last edited by a moderator:

mermaid

Full Member
Jan 16, 2021
5
104
0
UPDATE:
It seems like you were right about
Hey there, so, great post first of all. Finally someone who's actually doing some game hacking without pasting, thank god. Love how much info you provided, exactly what's needed, fucken hell why can't people post like this all the time...
Anyways.
So It's a long ass post and I just woke up but:

Is a GP exception, the best of way of going with problems like this is taking a look at what's causing it.


Great, now let's take a look at the movaps documentation.
As you can see, there are a few ways to trigger an exception:
1610880515957.png
and the most common one is to not align the operand on a 16-byte boundary.

What you just said here:

This is mostlikely the problem, it looks like an alignment issue. You might be calling the function with incorrect number of params most likely, but search for stack miss-alignment problems anyways.

Hope it helps. Keep us updated.
It seems like you were right about the alignment issue. I've only found one similar post on UC about this and they used their own structs, which was easy to align. I'm not creating any new structs really, so I'm clueless as to how I should align something I have no access to. Any ideas?
 
Community Mods