I am writing an application that seeks to scan the memory of a target process to search for certain kinds of “malware” signatures. I use VirtualQueryEx to discover the target processes memory regions, then iterate through that list using ReadProcessMemory to retrieve the memory for scanning.
This seems to work fine, for the most part, but in some cases I receive the subject 299 error, particularly when I am testing the program by running it against itself as the target process. I have been unable to find any definitive information on what exactly causes this error, or if there is any way to set things up to either avoid it or recover from it.
If anyone can enlighten me more specifically about what conditions in the target process can result in this error and what the best way to handle it might be, I would appreciate it.
This seems to work fine, for the most part, but in some cases I receive the subject 299 error, particularly when I am testing the program by running it against itself as the target process. I have been unable to find any definitive information on what exactly causes this error, or if there is any way to set things up to either avoid it or recover from it.
The most common cause of ERROR_PARTIAL_COPY is trying to cross the 32/64
boundary. Did you write a 32-bit or a 64-bit app?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The app is 64 bit (C#/WPF). I have attached it to both 32 and 64 bit processes, and it typically does not have a problem. Here is the declaration I use for ReadProcessMemory:
Interesting thing is, when I attached to itself, then shouldn’t everything should be in the 64-bit realm? But it is under that scenario that I see the most errors.
ERROR_PARTIAL_COPY also might happen in the case source memory cannot be read or target memory cannot be written (an exception has occurred during read/write operation). It looks that you read memory from ‘alive’ unfrozen process. The process might free memory or change pages’ attributes. So, it’s probably Ok to get this error from time to time.
Yep, I would expect those sorts of dynamic memory changes to be problematic, but I am also wondering if this error could occur if the page being accessed happens to be paged out. Does the call attempt to make the page resident in the remote process?