|
Consider the following two programs. One is the console application with this code:
int main()
{
char *p = new char[100];
return 0;
}
I run this program in Debug configuration and break on return 0 line. I the Watch window I see p variable value. The second program:
HANDLE hProcess = OpenProcess( PROCESS_VM_READ, FALSE ,
processId );
if ( hProcess == NULL ) return;
char p[100];
if (!ReadProcessMemory(hProcess,
address, p, 100,
&NumberOfBytesRead))
{
}
ReadProcessMemory is successful both in 32 and 64 bit (both program are compiled in Win32 or x64 configuration). Environment: Windows 7 64 bit, Visual Studio 2010. It also works in previous Windows versions.
Now I try the same in Windows 10 64 bit. Both programs in 32 bit - OK. 64 bit: ReadProcessMemory returns FALSE with last error 299: Only part of a ReadProcessMemory request was completed.
I tried:
1. To replace PROCESS_VM_READ with PROCESS_ALL_ACCESS
2. To run the second program as administrator
3. To use different Visual Studio versions (2010, 2015).
Still doesn't help. ReadProcessMemory fails in Windows 10 for 64 bit processes.
Edit: I tried to write this code from scratch, and it is working. So, the problem is somewhere in the original project, I don't know the solution yet, but API is working.
modified 25-Aug-15 6:24am.
|
|
|
|
|
|
Thanks, the post fixed. Real program contains the buffer parameter, of course.
|
|
|
|
|
Member 11917640 wrote: Real program contains ...
Then use copy and paste, so we can see exactly what your code is doing.
|
|
|
|
|
Thanks, this really helps.
|
|
|
|
|
What data type is the address variable?
What does the NumberOfBytesRead show after the call?
The difficult we do right away...
...the impossible takes slightly longer.
modified 24-Aug-15 13:28pm.
|
|
|
|
|
|
Thank you for the help, this code is working when rewritten from scratch, so the problem is somewhere else in the original project.
|
|
|
|
|
address,
Should that not be the contents of p, i.e. whatever variable p is pointing to?
|
|
|
|
|
Thank you for the help, this code is working when rewritten from scratch, so the problem is somewhere else in the original project.
|
|
|
|
|
|
I don't know yet, it is very old and messy code. Maybe I need to rewrite it from scratch and forget about this junk...
|
|
|
|
|
Does anyone know if there are any issues installing/running VB5 on Windows 10? Every time I try and Google this I only find articles relating to VB6.
I have an old legacy program in VB5 I need to maintain (until I finally get round to rewriting it in .NET... or, should I say, the client finally decides to pay me to...)
|
|
|
|
|
VB6 on Win10 is not even a supported scenario. Your software may or may not work, but there's no guarantee for tomorrow.
Use a Virtual Machine if you need to "update" something. Since you have a VB5 license, I'd expect that you'd also have an OS that supported the IDE at the time.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Well at the moment I've got the VB5 IDE running fine on Windows 7 on my laptop... am considering the Windows 10 upgrade on that, but don't want to lose VB5 in the process.
|
|
|
|
|
This is a highly unusual scenario. I'd suggest setting W10 on a VM and then installing VB5 on top there. That way, you can test to see whether or not the configuration will work together.
|
|
|
|
|
Yes, good idea - but I can't figure out how to get hold of the required product key if doing a clean install onto a VM...
|
|
|
|
|
Sorry if this si impertinent, to ask a follow-up question like this, but I wonder if you mght know this:
The difficulty with installing W10 in a VM is that it won't recognise it as a free upgrade from my W7, so will ask for a product key - which I don't have (or would need to buy.) But it occurs to me that I could instead go for the W10 upgrade and then, if necessary, re-install W7 in a VM on the same machine... the querstion then is: would it let me? Or would it tell me that the W7 product key has akready been used? As it'd be the same physical machine perhaps it would... but being a VM, maybe it won't... i.e. can one re-use a Windows product key on a VM on the same box as the orginal OS was installed?
|
|
|
|
|
I don't see why not? The VM runs isolated so it should be okay doing this.
|
|
|
|
|
Although legacy codes do run on Windows for sake of backward compatibility. But why would you even want to use such an old language on a new platform?
You may want to upgrade your current application to Windows Runtime. Windows Runtime and .NET framework are separate, Windows Runtime is the native framework provided with Windows 10, where as .NET framework is a separate product that you install.
Read this API[^] for Visual Basic on Windows Runtime.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~
|
|
|
|
|
As I said, it's an old application I wrote for a client way back in the early 90's which I still need to maintain occassionally. It was originally written in VB3, but apart form a minor update to VB5 in the mid 90's has remined pretty much teh same, and is still in use to day - a fact I am ever so slightly proud of  Of course it should be rewritten for a modern OS, but it's no small task, and the client likes it as is, so there is a certain amount of "if it ain't broke, don't fix it" going on. It will have to eb done day, but in the meantime....
|
|
|
|
|
Then the client should not switch operating system. If the OS updates and he breaks the application, then it IS broken.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I think the coder is the one who wants to switch in this case, and the IDE's compatibility is the primary concern. That client doesn't particularly sound like the sort of person who's likely to have ever ventured beyond windows XP. 
|
|
|
|
|
The coder is heading for problems; an unsupported IDE on an OS that was created years later. It is not just that it will be a 32-bit environment in a 64-bit OS, there will be more recent versions of COM-controls, something VB leans on. Those would be different on XP, generating a error if not compiled on XP.
"Unsupported" really means it could stop working tomorrow. It is never a good strategy to build on something that can be gone tomorrow.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Yes, you're right, and I realise this - but it's a large job to re-write the code, and I don't feel like doing it for free. So until the client is prepared to fork out for it, we'll just have to struggle on with the current code. As the earlier poster pointed out, this client is a tech dinosaur... I have pointed out to them the dangers of the path they are currently on.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
