Process.MainModule.FileName: "Only part of a ReadProcessMemory or WriteProcessMemory request was completed"
- I have searched google with this error in relation to Process.MainModule.FileName however none link with the error message, "Only part of a ReadProcessMemory or WriteProcessMemory request was completed".
There however was one thread on these forums suggest a 64 bit issue however that was soon excluded as it was reported also in a 32 bit enviroment. The marked answer to that thread suggested it is a security problem however I don't think anything has been changed in relation to that comapred to a 'clean' project.
- "If it is a security problem, you may try to run your application under the debugger" Process.MainModule failure
I am in-fact debugging this application through Visual Studio so I am not quite sure what to do next in the process of diagnosing this problem.
I am debugging using 32 bit in a 64 bit enviroment because of DirectX compatability issues, if anyone has any ideas on how I may be able to alter the 'security settings' (assuming what is quoted above is correct) to allow this it would be greatly appreciated.
Thanks
ShadowXVII | http://www.shadowsplace.net
All Replies
- Hi Shadow,
From your description it could be several things. What clearance are you running the process on? Do the results vary depending on the process clearance? Does the problem disappear if you put said file into the directory of bin\debug?
The problem I'm having with referencing .dll in other than the source directory appears to be analgous. I'll watch this thread closely, because it is possible that is also the answer to the question I am posing.
Best of luck to you,
John. - Thanks for your response,
The reason I need to find the Process.MainModule.Filename is that I have a GetForegroundWindow() handle and I need the full path of the owning process.
Currently I cycle through each open process checking the MainWindowHandle, and if there is a match, I check the Process.MainModule.Filename which should contain the data I am after. For example, I can get the window title from the process and the matching up works fine - I can cross reference what has got focus and what is returned. The issue is just the FileName, e.g. c:\windows\notepad.exe or something.
ShadowXVII | http://www.shadowsplace.net - Hi Shadow,
I see what you are doing now. If you are trying to scope out all processes from all users you must be running under Admin. I'd try running it under the userid it's running on and a process running under that userid. If the filename appears under that situation, it's definitely a security issue. If you still don't get the filename, then it's some sort of bug.
I hope that helps,
John. I only use an Admin account so there isn't any problems with security then.
I honestly say it would be more buggish if anything.
I have another 'clean' project as mentioned above and it works fine with exactly the same code. I must have changed something deep inside, although I have gone through all the UAC settings and stuff to no avail. They are identical to my test project... I can also exclude the cross platform (x64 and x86) because the test project works fine in both configurations.
Hmm, I am suprised UAC isnt in the spellcheck dictionary... seems 'spellcheck' isn't either... lol anyway.
ShadowXVII | http://www.shadowsplace.net- Hi Shadow,
The answer I only run under Admin, is not the correct response. I'm going to go out on a limb here, but this is how I've been visualizing Vista Admin logins.
When you are logged on as Admin, you are mostly a regular user. This is how they ensure that some background task doesn't hijack your clearance. Everybody complains about those annoying prompts that come up. The reality is, those "Annoying" prompts are the genius behind Vista. It gives you a head's up, that something is trying to run under elevated clearance. A great thing to know, because, nobody knows better than you if a process was started by you.
Now, if you are logged in as an Admin, something you should actually only need to do rarely, it does NOT mean that your program is running under Admin, it is, most likely running under your user aspect of your log-on.
Try this, exit your ide, then right click on the shortcut and pick "Run as Administrator", run your code like that, and you are utilizing true Administrative clearance. Realize though, this type of thing should only be done rarely. As to myself, I even develop most software utilizing my user log-on, and it gives me more than enough clearance to handle most tasks.
I'm curious what you find.
Regards,
John. - Hi Shadow,
If you've taken care of UAC stuff, then my last post is wrong. Not really sure what your issue is.
Wish I could be more help, but I really am not sure.
John. - It almost has to be a bug unless anyone can suggest otherwise from previous experience with this error?
There are only two posts I can find on these entire forums with in some ways the same error:
http://forums.msdn.microsoft.com/en-US/csharpgeneral/thread/f3d0d965-c024-423f-ab17-2390f962fedc/
http://forums.msdn.microsoft.com/en-US/csharpgeneral/thread/2ff95315-da55-4b01-9981-f11b5ae27183/
ShadowXVII | http://www.shadowsplace.net- Edited byShadow XVII Monday, June 02, 2008 1:20 PMPosts
- Hi Shadow,
Hopefully you found a resolution to this, but if not I thought up a few suggestions.
If you already have a working prototype, then you hold the keys to the answer.
If you developed it under 32 bit and are launching it on 64 bit, that's another key.
My suggestion is get a 64 bit version of Visual Studio, don't import your project into it, rather just paste the text of the code, if there is an interface, rebuild it under 64, but, for the reality check, a console application will tell you what you need to know.
It's a long shot, but it just might make the save.
Best of Luck to you. And, when you find the answer please post it, I'm curious as to what this is.
Thanks,
John. - Hi,
Just want to say that I had this exact problem, until I changed my "Solution Configuration" to Release instead of Debug in Visual Studio - voila - everything worked.
- I was about to reply when I realised I removed all code to do with this error. Instead of scanning each process running and comparing the exe name to the ones listed in the program, I made the program record the PID then compare that instead.
Thanks for your reply though, should anyone else have this problem they will be able to find your response.
ShadowXVII | http://www.shadowsplace.net - I hit the same problem. I'm running Windows 7 (64 bit) but compiling program in x86 (for legacy apis)
I am also looping through all processes using:
GetProcess(hWnd).MainModule.FileName
An interesting note: I've tracked down the offender... it's an explorer window.


