C＃-无法将IntPtr编组为正确的字符串

Question

This line of code has been baffling me!

string s = Marshal.PtrToStringAnsi((IntPtr)((Int32)Buffer + 
            Marshal.SizeOf(typeof(Struct))));

Here is the rest of the function.

            Api.LvItem lvItem = new Api.LvItem();
            IntPtr lpLocalBuffer = Marshal.AllocHGlobal(1024);
            uint pid;
            uint thread = Api.GetWindowThreadProcessId(hWnd, out pid);
            IntPtr hProcess = Api.OpenProcess(0x001f0fff, false, (int)pid);
            IntPtr lpRemoteBuffer = Api.VirtualAllocEx(hProcess, IntPtr.Zero, 1024, 0x1000, 4);
            lvItem.mask = 1;
            lvItem.iItem = index;
            lvItem.iSubItem = subitem;
            lvItem.pszText = (IntPtr)((int)lpRemoteBuffer + Marshal.SizeOf(typeof(Api.LvItem)));
            lvItem.cchTextMax = 50;
            Api.WriteProcessMemory(hProcess, lpRemoteBuffer, ref lvItem, Marshal.SizeOf(typeof(Api.LvItem)), 0);
            Api.SendMessage(hWnd, 0x1005, IntPtr.Zero, lpRemoteBuffer);
            Api.ReadProcessMemory(hProcess, lpRemoteBuffer, lpLocalBuffer, 1024, 0);
            string ret = Marshal.PtrToStringAnsi((IntPtr)((int)lpLocalBuffer + Marshal.SizeOf(typeof(Api.LvItem))));
            Marshal.FreeHGlobal((IntPtr)lpLocalBuffer);
            Api.VirtualFreeEx(hProcess, lpRemoteBuffer, 0, 0x8000);
            Api.CloseHandle(hProcess);
            return ret;

This code is used to get the text of each of the items in a listview of another process. I followed code (semi) from here : http://taylorza.blogspot.com/2009/08/archive-hacking-my-way-across-process.html

I'm sorry about the use of 0x1005. That's the code for the LV_GETITEM message.

I've narrowed it down to being related to the platform. It works on x64 and AnyCPU, while it does not work on x86. how would I go about changing the size differences in memory allocation, etc

It returns the value correctly when used in a console application. But when I use this code (and the rest of it) in a .DLL which is invoked via reflection, the code returns a string which is not correct. It appears empty, but is not in fact null. Perhaps just white space...

Has anybody had a similar experience with this trouble marshaling? It's been puzzling me for a good three hours now...

ANY help or ANY ideas or ANYTHING is greatly appreciated!

Answer 1

It appears that you are trying to read the memory of another process. You are sending an LV_GETITEM message to a list view control. This requires you to allocate memory in the virtual address space of that other process. Which you did with the call to VirtualAllocEx .

So far so good, but here's the kicker. You need the struct that you allocate to be the right layout for the target process. Now, let's assume that the target process is a 64 bit process. In which case the struct contains 64 bit pointers. When your process is also 64 bit then the struct that you defined will have 64 bit pointers. But when your process is 32 bit, any pointers in the struct will be 32 bit.

So, now we have a situation where the struct in your process has a different layout from the struct in the target process. That mismatch is enough to make all of this effort fail. In order to have any chance of making this work, you would need to declare your struct so that its layout matched the 64 bit layout. Given that you are only accessing a handful of fields, it may just be simpler to allocate a block of memory the right size (perhaps a byte array) and read/write the fields manually. And avoid struct marshalling.

Even then I am doubtful that a 32 bit process is even able to poke at a 64 bit process that way. You can do it in the other direction, from a 64 bit process to a 32 bit process. But I have tried and never succeeded in the direction that you are attempting.

All the indications are that you should stick to a 64 bit processes for this task. Or alternatively find an officially supported way to do whatever it is you are doing. For example, if you just want to read the contents of an explorer view, there's a shell API for that.

---

As an aside, please stop using magic constants instead of message identifier names. Nobody likes to try and understand what 0x1005 means. Declare a constant named LV_GETITEM . You also appear to perform no error checking at all. That's also going to make life hard for you. If one of the API calls fails, how will you ever find out about that?