OpenFUT/fifa17-recon/tools/acct_error_trace.md

# "Unable to retrieve account information. Please try again." — full trace (FIFA 17)

Clean-room. Sources: live `/proc/PID/mem` of FIFA17.exe (PID 3362053, base `0x140000000`),
cached image dumps `scratchpad/live_code.bin` (`0x140001000..0x144c23000`) +
`live_high.bin` (`0x144ed3000..0x151359000`), and `scratchpad/navregion.bin` (heap nav JSON).
All VAs absolute, stable across runs. New tools: `fx.py` (offline image str/dis/xref/callers),
`memsearch2.py` (ASCII+UTF-16 live search), `ptrscan.py`, `livedis.py`, `imgstr.py`.

---

## 0. Headline

The popup is **not** a login *failure*. It is the OSDK **generic alert** raised on a
**60-second timeout** while the OSDK login state machine waits for a step to complete.
The loc id is **`OSDK_A_R30B`**. The two states that raise it are
**`LoginStateConnect`** (waiting for all six `Util::fetchClientConfig` results) and
**`LoginStateLoadIspAccountInfo`** (waiting for the account country/locale from the OSDK
`'cnnc'` service). Both sit **upstream of `LoginStatePCLogin`**, which is where
`GetAuthCode` + `Authentication::login` live — which is exactly why neither is ever seen.

---

## 1. The string is not in the EXE

Live search (ASCII **and** UTF-16LE) over every readable mapping: 14 hits, **all in
anonymous heap**, zero inside the image range `0x140000000..0x151359000`.
So it is a **localized string loaded from data**, resolved at runtime.

Representative heap copies (ref-counted `[u16 refcnt=1][u16 len=0x39][u16 cap]` header,
MSVC debug heap `cd`/`fe` fill around them):

```
0x0000b7563b00  "Unable to retrieve account information. Please try again."
0x0000b79ad020  same
0x0000bc81ba70  same
0x00000db86f88  UTF-16LE render copy
0x000078f5380   entry in a 64-byte-slot string table (slots 0x78f5280,2c0,300,340,380,3c0,…)
```

## 2. Who owns the string — the popup record

Pointer-scan for holders of `0x78f5380` found an FE parameter record at `0x41abd7c0`,
a run of `{begin,end,cap,alloc}` string triples:

| field | value |
|---|---|
| `0x41abd798` | `"OnlineLoginViewModel"` (20 ch) |
| `0x41abd7c0` | `"ALERT_POPUP"` (11 ch) |
| `0x41abd7e0` | `"Unable to retrieve account information. Please try again."` (0x39 = 57 incl NUL) |

=> the text is the **`ALERT_POPUP` data-provider value of `OnlineLoginViewModel`**.

Confirming strings in the image:

```
0x143b4d6c0  OnlineLoginViewModel
0x143b4d890  UIFrameworkService::UIFDataProvider::PopupDp
0x143b4d8c0  LOGIN_POPUP
0x143b4d8e0  ALERT_POPUP
0x143b4d8f0  processLoginAlert
0x143b4d908  processBootLoginFailure
0x143b4d920  processLoginFailure
```

## 3. Which FE action sets it

`OnlineLoginViewModel` action trampoline **`0x147dc62c0`**
(`this=rcx, actionId=edx, params=r8`):

```
1471dc62dc: lea eax,[rdx-0x27a4]      ; actionId - 10148
1471dc62ea: cmp eax,0x6 ; ja  ->ret   ; only ids 0x27a4..0x27aa
1471dc6310: lea rdx,"StrParam" ; call [params->vt+0x28]   ; HasParam("StrParam")
1471dc6329: lea rdx,"StrParam" ; call [params->vt+0x20]   ; GetString("StrParam", &buf)
1471dc634d: call 0x147e03080          ; handler(this, id, buf)
```

Handler **`0x147e03080`** — one function, 7-way jump table
(`add ebx,[0x146b1d808]` where the dword = `-10148`; table at `0x1429f9148`):

| case | target | does |
|---|---|---|
| 0 | `0x147e03134` | sets `LOGIN_POPUP` |
| 1 | `0x147e03579` | sets `LOGIN_POPUP` |
| **2** | **`0x147e03682`** | **sets `ALERT_POPUP` (`0x147e03690`) + button `OSDK_OK` + callback `processLoginAlert`** |
| 3 | `0x147e03ac6` | `processBootLoginFailure` |
| 4 | `0x147e03b3e` | `ALERT_POPUP` + `OSDK_OK` + `processLoginFailure` |
| 5 | `0x147e04015` | popup hide |
| 6 | `0x147e03fe4` | popup show |

Action-id ↔ name registration block (`0x147de8330..0x147de8544`, `mov edx,<id>` +
`lea rdx,<name>` + `call [vt+0x20]`):

| id | name | case |
|---|---|---|
| `0x27a4` | `onlineLoginToEaPopup` | 0 |
| `0x27a5` | `onlineBootLoginToEaPopup` | 1 |
| **`0x27a6`** | **`evt_onlineAlertPopup`** | **2** |
| `0x27a7` | `evt_onlineBootLoginFailurePopup` | 3 |
| `0x27a8` | `evt_onlineLoginFailurePopup` | 4 |
| `0x27a9` | `onlineLoginPopupHide` | 5 |
| `0x27aa` | `onlineLoginPopupShow` | 6 |

**=> the popup is `evt_onlineAlertPopup` (0x27a6), message carried in param `StrParam`.**
It is explicitly *not* `evt_onlineLoginFailurePopup` / `evt_onlineBootLoginFailurePopup`.

## 4. The FE flow (`/online/onlineLoginFlow.nav`)

Recovered verbatim from `navregion.bin` (offset ~31456301); saved to
`scratchpad/onlineLoginFlow_raw.txt`:

```json
{ "name":"onlineLoginFlow"
, "onEnter":[["loadViewModel", ["OnlineLoginViewModel"]]]
, "states":[{ "transitions":[
      { "event":"evt_onlineAlertPopup",            "targets":["onlineAlertLoginPopup"] }
     ,{ "event":"evt_onlineBootLoginFailurePopup", "targets":["onlineFailureLoginPopup"] }
     ,{ "event":"evt_onlineLoginFailurePopup",     "targets":["onlineFailureLoginPopup"] }
     ,{ "event":"evt_online_disconnected",         "targets":["processLoginFailure"] } ...]
  ,"states":[
     { "name":"startLoginWithoutMultiplayerCheck"
      ,"onEnter":[["sendScreenEvent", ["OnlineLogin", "0"]]] }
    ,{ "name":"onlineAlertLoginPopup"
      ,"onEnter":[["sendAction", ["onlineLoginPopupShow"]]]
      ,"onExit" :[["sendAction", ["onlineLoginPopupHide", "ALERT_POPUP"]]]
      ,"states":[{ "name":"onlineAlertLoginIdle"
                  ,"transitions":[{"event":"processLoginAlert","targets":["processLoginAlert"]}]}
                ,{ "name":"processLoginAlert"
                  ,"onEnter":[["sendScreenEvent", ["ProcessLoginAlert"]]] }]} ...]}]}
```

Entry per `nav/root.nav`: `launchFUTFlow` (`/online/origin.nav`) →`OriginIsOnlineTrue`→
`futBlazeLogin` (`/online/onlineLoginFlow.nav`, entry `startLoginWithoutMultiplayerCheck`)
→ `loginSuccess` → `CheckFUTRosters` → `futFlow`.

**We are inside `futBlazeLogin`.** `origin.nav` already emitted `OriginIsOnlineTrue`
(our LSX work) — the wall is one layer deeper.

## 5. The C++ that raises it — OSDK login state machine

EA **Online SDK (OSDK) 8.01.03.00-fifa.01**; source paths embedded, e.g.
`E:/p4/fifafb/rl/empatch/TnT/Code/fifa/gamemodes/extern/OSDK/8.01.03.00-fifa.01/source/common/modulemanager.cpp`.

States are classes whose vtable slot 1 is a `GetName()` thunk (`lea rax,<name>; ret`)
in `0x14719b3xx`; vtable slot 4 (`+0x20`) is the per-tick handler; slot 8 (`+0x40`) is
"advance to next state".

| state | vtable | handler (vt+0x20) |
|---|---|---|
| `LoginStateIsp` | `0x14395bc78` | `0x1471b45f0` |
| `LoginStateConnect` | `0x14395be20` | `0x1471b4a40` |
| `LoginStateLoadIspAccountInfo` | `0x14395bd18` | `0x1471b4b40` |
| `LoginStatePCLogin` | `0x14395c180` | `0x1471b58e0` |

Shared alert builder **`0x147190e80`** — `OSDK_RaiseError(this, Notification* out, int code, const char* locId)`:

```
147190e9b: mov byte [rdx],1          ; notif type = error
147190e9e: mov byte [rdx+2],1
147190ea2: mov [rdx+8],r8d           ; numeric code
147190ebd: lea rcx,[rdi+0xc] ; call 0x145e27ff0   ; strcpy(notif+0xc, locId)
147190ee0: mov byte [rdi+0x20b],0
147190f16: lea rdx,"error" ; lea rcx,"osdk" ; call 0x146ec02d0   ; telemetry osdk/error/%d
```

It has **16 call sites**, all inside the login-state cluster `0x1471b4xxx..0x1471b7xxx`
— i.e. it is *the* OSDK "raise login alert with loc id" entry point. The notification
carries the **loc-id string**, which the OSDK→FE bridge resolves to localized text and
delivers as `StrParam` on `evt_onlineAlertPopup`.

Loc ids raised by neighbouring states (for contrast):

```
0x14395cdd8  OSDK_SIGNIN_REQUIRED            (LoginStateIsp, default branch)
0x14395ce48  OSDK_ONLINE_OUTDATED_PATCH      (LoginStateIsp, NetConn 4CC '-upp')
0x14395ce68  OSDK_ONLINE_DISABLED_PARENTAL   (LoginStateIsp, NetConn 4CC '-adu')
0x14395cdc8  OSDK_ERROR
0x14395c6b8  OSDK_A_R30B                     <<< our popup
```

### 5a. `LoginStateConnect` — handler `0x1471b4a40` (STRONGEST CANDIDATE)

Sub-state in `[this+0x20]`, deadline in `[this+0x24]`.

```
; ---- sub-state 0 : kick off ----
1471b4b0d: mov rcx,[rbx+0x28]
1471b4b11: call 0x1471a8970          ; issue all client-config loads
1471b4b16: lea eax,[rdi+0xea60]      ; rdi = now(ms);  0xea60 = 60000 = 60 s
1471b4b1c: mov [rbx+0x20],1          ; -> polling
1471b4b23: mov [rbx+0x24],eax        ; deadline = now + 60 s

; ---- sub-state 1 : poll ----
1471b4ab4: mov rax,[rbx+0x28] ; xor edx,edx
1471b4aba: mov r8d,[rax+0x60]        ; entry count
1471b4abe: test r8d,r8d ; je -> sub-state 3      ; nothing pending => done
1471b4ac3: mov r9d,[rax+0x64]        ; stride
1471b4ac7: mov r10,[rax+0x58]        ; array base
1471b4acb: (loop) mov rcx,[base + idx*stride]
1471b4ad5:        cmp byte [rcx+0x60],0
1471b4ad9:        je  0x1471b4af4                ; <-- this entry NOT ready
1471b4ae2: mov [rbx+0x20],3          ; all ready -> success
1471b4af4: sub edi,[rbx+0x24]        ; now - deadline
1471b4af7: test edi,edi ; jle -> ret ; still inside the 60 s window: keep waiting
1471b4afb: mov [rbx+0x20],2          ; TIMEOUT

; ---- sub-state 2 : alert ----
1471b4a86: lea r9,"OSDK_A_R30B" ; xor r8d,r8d ; mov rdx,r10 ; mov rcx,rbx
1471b4a9b: call 0x147190e80
```

`0x1471a8970` iterates the same array and for each entry calls `0x1471a89f0`, which:

```
1471a8a20: mov byte [rcx+0x60],0     ; clear the "ready" flag the poll loop reads
1471a8a2c: lea r8,"LoadCfg:%s"       ; 0x143962390
```

**`LoadCfg:%s` is `Util::fetchClientConfig`.** The config-name list sits immediately
after it, and matches the six CFIDs we observe on the wire byte-for-byte:

```
0x143962be8  OSDK_CORE
0x143962bf8  OSDK_CLIENT
0x143962c08  OSDK_NUCLEUS
0x143962c18  OSDK_WEBOFFER
0x143962c28  OSDK_ABUSE_REPORTING
0x143962c40  OSDK_TICKER
```

The entries are `ResourceLoader` objects (`0x143962960..0x143962b60`, states
`LOADED` / `LOADING` / `NOT_FOUND`, `ResourceLoader::ResourceFailure()`).
`[entry+0x60]` is the "loaded OK" flag. **An empty / failed config reply leaves it 0.**

### 5b. `LoginStateLoadIspAccountInfo` — handler `0x1471b4b40` (SECOND CANDIDATE)

Same 4-sub-state shape:

```
; sub-state 0 : GetService('cnnc')->[+0x38]()->[+0xb0]() ; -> sub-state 3
1471b4e9d: mov rcx,[0x144b86bf8] ; mov edx,0x636e6e63 ('cnnc')
1471b4eac: call [rax+0x60]       ; mgr->GetService('cnnc')
1471b4eb5: call [rdx+0x38]
1471b4ebe: call [rdx+0xb0]

; sub-state 1 : poll the same accessor
1471b4e6d: call [rdx+0xb0] -> eax
1471b4e73: test eax,eax ; je  -> timeout check      ; 0     = not resolved
1471b4e77: cmp eax,0x5a5a ; jne -> sub-state 3      ; 'ZZ'  = placeholder
1471b4e7e: sub ebx,[rdi+0x24] ; jle -> ret          ; inside deadline: keep waiting
1471b4e85: mov [rdi+0x20],2                         ; TIMEOUT

; sub-state 2 : alert
1471b4e1f: lea r9,"OSDK_A_R30B" ; call 0x147190e80

; sub-state 3 : SUCCESS — parse the account locale
1471b4b84: mov rsi,[0x144b86bf8] ; mov rdx,[rsi+0xb0]   ; char* country/locale
           ... packs 4 chars, lowercases pair 1 (|0x20), uppercases pair 2 (&0xdf)
1471b4df0: call [rax+0x188] ; mov [rax+0x52c],ebx       ; store packed "enUS"-style u32
1471b4e1c: jmp [this->vt+0x40]                          ; advance to next login state
```

`0x5a5a` is literally **`"ZZ"`** — the unknown-country placeholder. So this state waits
for a **real 2-letter account country code** from the OSDK `'cnnc'` (connection /
Nucleus adaptor) service and alerts `OSDK_A_R30B` if it never arrives.

Operation names registered in the same module manager, right beside `LoadCfg:%s`:

```
0x1439623c0  FetchAccountInfo        <<< semantic match for the popup text
0x1439623d8  UpdateAccountInfo
0x1439623f0  LookupOriginPersona
0x143962408  FetchOriginPersona
0x143962420  CreateOriginPersona
0x143962598  "Operation timed out.  Name = [%s], Handle = [%u]"
```

---

## 6. Why this matches the observed behaviour exactly

| observation | explanation |
|---|---|
| `preAuth` → `ping` → **6× `fetchClientConfig`** → then popup | `LoginStateConnect` sub-state 0 issues exactly these 6 `LoadCfg:` requests |
| popup appears after a wait, not instantly | hard-coded **60 000 ms** deadline (`lea eax,[rdi+0xea60]`) |
| we answer all 6 `fetchClientConfig` with **empty** replies | `ResourceLoader` never reaches `LOADED`, `[entry+0x60]` stays 0 → poll never satisfied → timeout |
| popup is the **alert**, not the login-failure popup | `evt_onlineAlertPopup` (0x27a6), not 0x27a7/0x27a8 — the flow never reported a login failure, it timed out earlier |
| **`GetAuthCode` never requested** | `Origin::OriginSDK::RequestAuthCodeSync` / `LSXRequest<lsx::GetAuthCodeT,…>` is driven from `LoginStatePCLogin`, which is **downstream** and never entered |
| **`Authentication::login` (1/0x0A) never sent** | same reason — the state machine aborts before it |
| client sends `Authentication` 1/0x46 then reconnect-loops | the OSDK teardown path after the alert (`LoginStateLogout`) |
| nucleusConnect stub on :42131 gets zero requests | the client gets its Nucleus config **from `fetchClientConfig OSDK_NUCLEUS`**, which we return empty — so it never learns a Nucleus URL to dial |

The last row is the key causal loop: **`OSDK_NUCLEUS` is where the Nucleus/account
endpoints come from.** Returning it empty both (a) fails the `LoginStateConnect` ready
check and (b) guarantees the account-info fetch can never resolve, which is why *both*
`OSDK_A_R30B` sites are armed.

---

## 7. What was NOT proven

1. **`OSDK_A_R30B` → that exact English text** is inferred, not read. The loc DB lives in
   compressed Frostbite superbundles (`Data/Win32/loc/en.toc` + `.sb`, chunked); the
   plain text is not greppable on disk and the game exited before I could read the live
   loc table. Confidence is high (it is the only alert id raised by the two
   "waiting for account data" states, and every other login alert id has a clearly
   different meaning), but it is one unverified link.
2. **Which of the two sites fired** (`LoginStateConnect` vs `LoginStateLoadIspAccountInfo`).
   `LoginStateConnect` is the stronger candidate because the observed Blaze traffic stops
   exactly at its wait condition.

### Cheap runtime confirmations (next live run)

* Read `[state+0x20]` / `[state+0x24]` while the spinner is up — sub-state 2 = timeout hit.
* Breakpoint / patch-log `0x147190e80` and dump `r9` (the loc-id string) — this names the
  alert with zero ambiguity and works for every login alert.
* Grep `/tmp/lsx.log`-style logging for the OSDK telemetry event `osdk` / `error` / `%d`
  emitted at `0x147190f24`.

---

## 8. Actionable conclusion

**Layer implicated: Blaze `Util::fetchClientConfig` (9/0x01) — not LSX, not Nucleus HTTP.**

The Origin/LSX layer is already satisfied (`origin.nav` emitted `OriginIsOnlineTrue`).
The wall is the **first Blaze step after preAuth**: the client demands non-empty client
configs for all six CFIDs and blocks for 60 s, then alerts.

Fix order:
1. Return **real, non-empty** `fetchClientConfig` maps for `OSDK_CORE`, `OSDK_CLIENT`,
   **`OSDK_NUCLEUS`**, `OSDK_WEBOFFER`, `OSDK_ABUSE_REPORTING`, `OSDK_TICKER`
   (note: **`OSDK_TICKER`**, per the in-binary list at `0x143962c40` — earlier notes
   recorded `OSDK_XMS_ABUSE_REPORTING` as the 6th; verify against the live capture).
   `OSDK_NUCLEUS` must carry auth/account URLs pointed at our stub.
2. That should let `LoginStateConnect` reach sub-state 3 and advance to
   `LoginStateLoadIspAccountInfo`, which then needs the account **country code** to come
   back as a real 2-letter code (not `0`, not `"ZZ"`) from the `'cnnc'` service.
3. Only then does `LoginStatePCLogin` run — and that is where **LSX `GetAuthCode`** will
   finally be requested, followed by Blaze `Authentication::login` (1/0x0A).