STM32U5, FileX crashes to hardfault when doing FileX in seperate ThreadX with seperate Byte Pool

Question

Working on STM32U5A5 experimental code, I have a separate byte pool for ThreadX stuff (queue, semp, about 3 threads, static setup). I also have a separate byte pool for FileX which is working fine including new filename, write data and read data. When I move the fx_file_open(...) from fileX thread structure into ThreadX (other byte pool where the thread/semp stack is). It crashed under a hard fault (corrupt stack?). Based on the investigation, without going too deep and I have looked into demo code that does not run FileX, which suggests all file handling stuff must stay in the filex byte pool including threads.

I have attempted to find something in Azure document and STM32 document but could not find something to affirm the above arrangement. Is there bug or restriction in using FileX function in a separate thread from a separate byte pool?

How the Azure ThreadX/FileX work together with two separate byte pools, are threads they fully independent or ???

Why the thread side does not work well with filex function?

Any suggestions or guidelines to address this understanding would be appreciated.

PS: My theory is that the filex thread sets up the media (after the usual filex init) within the filex byte pool and then the thread is completed, so the content of the filex stack becomes outdated since the thread is no longer active (exit itself out). so any file command in another thread in a separate byte pool would be crashed. Letr me know if this is the case.