VMMDLL_Initialize Issues

[americanhawk1]

VMMDLL_Initialize fails after being run(as non-admin, and admin). I'm supplying it with the arguments LPSTR argv[] = { (LPSTR)"", (LPSTR)"-device", (LPSTR)"fpga" }.

I've tried using the VMMDLL_InitializeEx to print out some error information, but wszUserText is always empty. I've correctly linked the libraries I need to use PCILeech, but I don't think this would be the issue as the project likely wouldn't compile. I also have all the DLLs required to run the process, in the projects directory, and I get no errors on that front.

I'm using a DMA Card that's recognized by Device Manager on Windows, and can also be found and used by pcileech.exe when running commands like probe. I also have all the correct drivers installed, and have FTD3XX.dll in my projects directory.

I'm not sure where to go from here, or what else to test. I can't really debug as the function being called is exported and I cannot single step the code.

Any ideas? Thanks!

int main()
{
    VMM_HANDLE result;
    LPSTR argv[] = { (LPSTR)"", (LPSTR)"-device", (LPSTR)"fpga" };
    DWORD argc = sizeof(argv) / sizeof(argv[0]);

    result = VMMDLL_Initialize(argc, argv);
    if (result) {
        printf("VMMDLL_Initialize: Initialization successful.\n");
    }
    else {
        printf("VMMDLL_Initialize: Initialization failed.\n");
    }

    return 0;
}

[ufrisk]

The VMMDLL_InitializeEx is more a specialty function and the error info struct isn't providing the kind of errors you're looking for. Better to use the normal function as you do in the above example.

You can try adding parameters: "-printf", "-v" or "-printf", "-v", "-vv" (for additional logging). or "-printf", "-loglevel", "7" (for maximum loggning).

Please let me know if you have success.

[americanhawk1]

Thank you for the quick response!

Here's a snippet of the output:

LcMemMap_AddRange: 0000000000000000-000000000009ffff -> 0000000000000000
LcMemMap_AddRange: 0000000000100000-00000010bfffffff -> 0000000000100000
LeechCore v2.14.2: Open Device: fpga
[CORE]     DTB  located at: 00000000001ad000. MemoryModel: X64
[CORE]     Initialization Failed. Unable to locate ntoskrnl.exe. #3
VmmProc: Unable to auto-identify operating system for PROC file system mount.
         Specify PageDirectoryBase (DTB/CR3) in -cr3 option if value if known.
[CORE]     Failed to initialize.

[CORE]     SHUTDOWN COMPLETED (0000000000A2D040).

[ufrisk]

It reads some memory at least very early in the process and then fail. You can try to use a memory map: https://github.com/ufrisk/LeechCore/wiki/Device_FPGA_AMD_Thunderbolt acquired with Sysinternals RAMMap and it may help.

Save the ranges to a file and add it with parameters "-memmap", "c:\\path\\to\\memmap.txt"

A reboot may be required after your last attempt.

[americanhawk1]

I restarted, acquired my physical ranges and ran the function with the new parameters to no avail. I'll post what I used down below:

RamMap:

PhysicalPages.txt:

Visual Studio:

int main()
{
    VMM_HANDLE result;
    LPSTR argv[] = { (LPSTR)"-device", (LPSTR)"fpga", (LPSTR)"-v",  (LPSTR)"-printf", (LPSTR)"-vv", (LPSTR)"-memmap", (LPSTR)"C:\\Users\\theco\\source\\repos\\DMA\\DMA\\PhysicalPages.txt"};
    DWORD argc = sizeof(argv) / sizeof(argv[0]);

    result = VMMDLL_Initialize(argc, argv);
    if (result) {
        printf("VMMDLL_Initialize: Initialization successful.\n");
    }
    else {
        printf("VMMDLL_Initialize: Initialization failed.\n");
    }

    return 0;
}

Output:

LcMemMap_AddRange: 0000000000000000-000000000009ffff -> 0000000000000000
LcMemMap_AddRange: 0000000000100000-000000ffffffefff -> 0000000000100000
LeechCore v2.14.2: Open Device: fpga
LcMemMap_AddRange: 0000000000001000-000000000009dfff -> 0000000000001000
LcMemMap_AddRange: 000000000009f000-000000000009ffff -> 000000000009f000
LcMemMap_AddRange: 0000000000100000-0000000037da2fff -> 0000000000100000
LcMemMap_AddRange: 000000003afff000-000000003affffff -> 000000003afff000
LcMemMap_AddRange: 0000000100000000-00000010bfffffff -> 0000000100000000
[CORE]     Initialization Failed. Unable to locate valid DTB. #2
VmmProc: Unable to auto-identify operating system for PROC file system mount.
         Specify PageDirectoryBase (DTB/CR3) in -cr3 option if value if known.
[CORE]     Failed to initialize.

[CORE]     SHUTDOWN COMPLETED (0000000000A46040)

[ufrisk]

RAMMap looks alright. But it seems to be failing earlier on this time. It's not able to locate DTB at all. In first printout it did locate this. [CORE] DTB located at: 00000000001ad000. MemoryModel: X64

Can you retry with this after you shut down the target computer and then powered it on again?

If the shutdown/Startup does not work can you read memory with pcileech.exe?, i.e. pcileech.exe display -min 0x1000 -device fpga -v

[americanhawk1]

Same results after restarting the target machine.

I restarted again and tried the command you sent(I wasn't sure if I was supposed to copy and run it verbatim) . This is the output:

Could the issue be a bad card? I know it's always a possibility, but as far as I can tell, it functions correctly in terms of being recognized by the operating system, and can be found by PCILeech. It can also probe memory, and does seem to read memory up until it fails (I think?).

Also, if you're curious what my memory probe looks like:

DEVICE: FPGA: ScreamerM2 PCIe gen2 x1 [300,25,500] [v4.11,0400] [ASYNC,NORM]
FPGA: TINY PCIe TLP algrithm auto-selected!
 Memory Map:
 START              END               #PAGES
 0000000000000000 - 000000000009ffff  000000a0
 00000000000c0000 - 000000003affffff  0003af40
 000000003d020000 - 000000003effffff  00001fe0
 0000000100000000 - 00000010bfffffff  00fc0000

 Current Action: Probing Memory
 Access Mode:    Normal
 Progress:       68608 / 68608 (100%)
 Speed:          155 MB/s
 Address:        0x00000010C0000000
 Pages read:     16764864 / 17563648 (95%)
 Pages failed:   798784 (4%)
Memory Probe: Completed.

EDIT:

I thought I would mention that running this command pcileech.exe display -min 0x1000 -v -vv -device fpga://algo=1 seems to allow me to READ from memory address 0x1000. I'll show the output below:

. . . bunch of probably useless stuff above this . . .
LcMemMap_AddRange: 0000000000000000-000000000009ffff -> 0000000000000000
LcMemMap_AddRange: 0000000000100000-000000ffffffefff -> 0000000000100000
LeechCore v2.14.2: Open Device: fpga
Memory Display: Contents for address: 0x0000000000001000
0000    e9 4d 06 00 01 00 00 00  01 00 00 00 3f 00 18 10   .M..........?...
0010    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0020    00 00 00 00 00 00 00 00  00 00 00 00 00 9b 20 00   .............. .
0030    00 00 00 00 00 00 00 00  ff ff 00 00 00 93 cf 00   ................
0040    00 00 00 00 00 00 00 00  ff ff 00 00 00 9b cf 00   ................
0050    00 00 00 00 00 00 00 00  00 50 d9 37 00 00 00 00   .........P.7....
0060    7c 16 00 00 30 00 da 16  00 00 10 00 00 00 00 00   |...0...........
0070    50 7a 7f 7d 05 f8 ff ff  00 80 00 c0 81 f7 ff ff   Pz }............
0080    06 01 07 00 06 01 07 00  01 09 00 00 00 00 00 00   ................
0090    33 00 05 80 00 00 00 00  00 00 00 00 00 00 00 00   3...............
00a0    00 d0 1a 00 00 00 00 00  f8 0e 35 00 00 00 00 00   ..........5.....
00b0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00c0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00d0    00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00e0    00 00 00 00 00 00 57 00  b0 3f d9 22 80 d4 ff ff   ......W..?."....
00f0    00 00 00 00 00 00 ff 0f  00 10 d9 22 80 d4 ff ff   ..........."....

EDIT: I tried using fpga://algo=1 in my application and it didn't work, but when I tired using fpga://algo=2, vmm.dll was able to initialize. If I were to use fpga://algo=2 on pcileech.exe, it doesn't work. I'm not really sure what's going on, but this seems to give me a handle.

Here's my argv array: LPSTR argv[] = { (LPSTR)"-device", (LPSTR)"fpga://algo=2", (LPSTR)"-printf", (LPSTR)"-v" }

[ufrisk]

oh, thanks for the update, this was a new quite strange one.

But if fpga://algo=2 works it's fine I guess. It's only slightly less performant than the default algorithm, but should mostly be OK.

Issue "resolved" then I guess?

[americanhawk1]

I would say it's resolved!

I do have a couple questions though... do you have any idea why this would happen in the first place? This isn't an isolated case, as I've seen at least one other occurrence. I looked briefly for information on the fpga://algo command, but I couldn't find anything, so I couldn't really dig into the issue.

Also, why does algo=1 work on pcileech.exe, and algo=2 works when initializing vmm.dll? I assume they both work similarly. Should I be worried that other issues might crop of down the line?

EDIT:

I'm not sure if this actually represents the speed of fpga://algo=2, but if it does, this speed is fairly respectable.

[ufrisk]

It goes as: algo=0 (default) is 4kB page sized reads with overlapped io algo=1 (tiny reads) is 128 byte sized reads synchronous timing based. algo=2 is 4kB page sized reads synchronous timing based. algo=3 = same as algo=1.

algo=2 is closer to algo=0 than 1.

I have no explanation why 2 is working with MemProcFS but not with PCILeech. They use exactly the same backend so I find that extremely strange. Maybe DMA stopped working and a reboot is required?

And huge thanks for the sponsorship :)

And let me know if you should run into any issues in the future or have any questions.

[themaoci]

i happen to have similar problem by using pcieleech and data connection ot same machine (while testing) altho my lib was using algo=0 which is very unstable algo=1 and algo=2 didnt rly changed much in the speed area but failed pages disapeared and after doing probe test problem has been resolved on all algo's it seems... and speeds sems to be similar with algo=1 beingmore fluctuant

V:\Windows Folders\User - Desktop\DMA Stuff\PCILeech>pcileech.exe probe -device fpga://algo=0

WARNING: 'probe' may cause the device to stop working until a reboot on AMD or
         Thunderbolt systems and is discouraged. See link for additional info:
         https://github.com/ufrisk/LeechCore/wiki/Device_FPGA_AMD_Thunderbolt

 Memory Map:
 START              END               #PAGES
 0000000000000000 - 000000000009ffff  000000a0
 00000000000c0000 - 0000000060ffffff  00060f40
 00000000000c0000 - 000000006bffffff  0006bf40

 Current Action: Probing Memory
 Access Mode:    Normal
 Progress:       1728 / 83967 (2%)
 Speed:          288 MB/s
 Address:        0x000000006C000000
 Pages read:     442336 / 21495680 (2%)
 Pages failed:   32 (0%)

V:\Windows Folders\User - Desktop\DMA Stuff\PCILeech>pcileech.exe probe -device fpga://algo=1

WARNING: 'probe' may cause the device to stop working until a reboot on AMD or
         Thunderbolt systems and is discouraged. See link for additional info:
         https://github.com/ufrisk/LeechCore/wiki/Device_FPGA_AMD_Thunderbolt

 Memory Map:
 START              END               #PAGES
 0000000000000000 - 000000000009ffff  000000a0
 00000000000c0000 - 0000000059ffffff  00059f40
 00000000000c0000 - 0000000063ffffff  00063f40

 Current Action: Probing Memory
 Access Mode:    Normal
 Progress:       1600 / 83967 (1%)
 Speed:          320 MB/s
 Address:        0x0000000064000000
 Pages read:     409568 / 21495680 (1%)
 Pages failed:   32 (0%)

V:\Windows Folders\User - Desktop\DMA Stuff\PCILeech>pcileech.exe probe -device fpga://algo=2

WARNING: 'probe' may cause the device to stop working until a reboot on AMD or
         Thunderbolt systems and is discouraged. See link for additional info:
         https://github.com/ufrisk/LeechCore/wiki/Device_FPGA_AMD_Thunderbolt

 Memory Map:
 START              END               #PAGES
 0000000000000000 - 000000000009ffff  000000a0
 00000000000c0000 - 0000000043ffffff  00043f40
 00000000000c0000 - 000000004effffff  0004ef40

 Current Action: Probing Memory
 Access Mode:    Normal
 Progress:       1264 / 83967 (1%)
 Speed:          316 MB/s
 Address:        0x000000004F000000
 Pages read:     323552 / 21495680 (1%)
 Pages failed:   32 (0%)