VMMDLL_ Initialize arguments issue

[TiAmo7]

What are the initialization arguments for VMMDLL_ Initialize？What functions do they represent respectively?

[ufrisk]

Hi, there is a guide here: https://github.com/ufrisk/MemProcFS/wiki/_CommandLine

There are no particular order in the command line arguments in that guide entry though. The -device command line entry corresponds to a LeechCore supported "device" and may have individual sub-arguments. https://github.com/ufrisk/LeechCore/wiki

Please let me know if this helps and answer your question.

[TiAmo7]

Thank you. I have another question. When writing a program that requires high speed for real-time memory reading, I always stop for about 2 seconds every time I execute it for about one or two minutes before continuing to execute it

[ufrisk]

I quite don't understand what you mean.

There are some periodic background refreshes that will take priority at times which may delay your regular operations. 2 seconds sounds like a fairly long time though. These refreshes are necessary since things otherwise will star to drift. You may however disable them and then trigger refreshes manually should you need to.

Or do you mean you stop yourself for some time for some reason?

[TiAmo7]

How is it manually refreshed? How should I set it up? Or which function should be called?

[ufrisk]

Disable automatic refreshes with: -norefresh

Perform manual refreshes with:

VMMDLL_ConfigSet(hVMM, VMMDLL_OPT_REFRESH_FREQ_FAST, 1);
VMMDLL_ConfigSet(hVMM, VMMDLL_OPT_REFRESH_FREQ_MEDIUM, 1);
VMMDLL_ConfigSet(hVMM, VMMDLL_OPT_REFRESH_FREQ_SLOW, 1);

I'd really recommend against this approach though and just leave the defaults on unless there is an absolute need to do this. If the background refresh is not initiated things will start to drift and get out to date and stop working in strange ways after a short while.

[TiAmo7]

Okay, I will test if there are still any issues after using manual refresh. If it can solve the problem, that would be great. Is the third parameter of ConfigSet to set the refresh time?

[ufrisk]

It's to perform the actual refresh (since refreshes are otherwise disabled).

[ygnice]

When reading at high speeds, high latency is often encountered: ` while (true) { auto start = std::chrono::high_resolution_clock::now();

    DWORD_PTR buffer = 0;

    VMMDLL_MemReadEx(hVMM, pid, base, (PBYTE)&buffer, sizeof(DWORD_PTR), 0, VMMDLL_FLAG_NOCACHE);

    auto end = std::chrono::high_resolution_clock::now();
    auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();
    if (duration > 0) {
        printf("Render Time: %dms\n", duration);
    }
}

`

[ufrisk]

@ygnice

• If you're not on v4.11 or v4.12 of the firmware - upgrade.
• Ensure your program is single-threaded (i.e. you don't have multiple threads accessing the device at the same time).
• Disable automatic refreshes (as described above in this thread, but not recommended) with startup option: -norefresh
• Use flags: VMMDLL_FLAG_NOCACHE|VMMDLL_FLAG_NOPAGING

will this better the situation?

[TiAmo7]

What should I do if I want to refresh VMMDLL_OPT_REFRESH_FREQ_TLB separately and disable other refreshes?

[ufrisk]

add startup option -norefresh to disable all automatic refreshes. then issue the ConfigSet command with VMMDLL_OPT_REFRESH_FREQ_TLB manually at your preferred intervals and see how it works.

[ufrisk]

@762278834 are you read efficiency dropping from 4ms to 50ms on all reads, or is it like the screenshot above in which it only happens to some reads?

if it's happening to all reads, what happens if you restart the pcileech test application, do it still have slow read speeds?

[ufrisk]

@762278834 as you've already noticed the refreshes are required or else things will start to fall apart after a while, you won't be able to read new allocations etc. If you run with the -norefresh startup option you'd need to refresh manually with VMMDLL_SetConfig as described above in the thread.

There is no way around this. You can't stop refreshes and expect things to go fine, and when you do a refresh it will slightly impact your read speeds when the refresh is taking place.

[ufrisk]

I'm closing this issue since I think I've answered what those delays may be about and also provided some kind of (even if not ideal) solution to it.