Question marks in memory window

Printable View

January 2nd, 2013, 05:32 AM
D_Drmmr

1 Attachment(s)

Question marks in memory window

While debugging an application I ran into what seems to be a dangling pointer. When I copy the pointer's address into the memory window in VS2008 (while debugging), I see a bunch of question marks instead of normal data - see attached image.
Does anyone know what that means (i.e. what has happened to the memory)? Am I looking at a section of memory that has been unpaged (if that's the correct term)?

Attachment 30787

Thanks!
January 2nd, 2013, 06:07 AM
vcdebugger

Re: Question marks in memory window

Since it is a dangling pointer it is pointing to some junk memory.
January 2nd, 2013, 06:54 AM
Eri523

Re: Question marks in memory window

I've never seen this in my own debugging sessions, but I'd interpret that as an address range which has not been assigned any physical memory at all (neither RAM nor page file space). I'm not sure if that's actually what you meant by "unpaged", but I think programs like Process Explorer woud call that "uncommited". This assumption is supported by the fact that the address where the "real" data starts (0x0769E000) is on a 4k boundary, which is the most commonly used memory page size. I don't think that memory has just been paged out (i.e. stored in the page file and then released the physical RAM), because then it would certainly have been paged back in transparently on demand from the debugger.

Do you get a 0xC000005 thrown for that pointer? Accessing uncommitted addresses is one of the most common reasons for this exception, even when just attempting a read.
January 2nd, 2013, 07:50 AM
D_Drmmr

Re: Question marks in memory window

Quote:

Originally Posted by vcdebugger

Since it is a dangling pointer it is pointing to some junk memory.

Thanks for your response. However, I'm not sure if it is a dangling pointer. I'm trying to figure out what happened to the memory (or pointer). I've never noticed the question marks in the memory window before and was wondering if they have a special meaning.
January 2nd, 2013, 08:12 AM
D_Drmmr

Re: Question marks in memory window

Quote:

Originally Posted by Eri523

I've never seen this in my own debugging sessions, but I'd interpret that as an address range which has not been assigned any physical memory at all (neither RAM nor page file space). I'm not sure if that's actually what you meant by "unpaged", but I think programs like Process Explorer woud call that "uncommited". This assumption is supported by the fact that the address where the "real" data starts (0x0769E000) is on a 4k boundary, which is the most commonly used memory page size. I don't think that memory has just been paged out (i.e. stored in the page file and then released the physical RAM), because then it would certainly have been paged back in transparently on demand from the debugger.

Do you get a 0xC000005 thrown for that pointer? Accessing uncommitted addresses is one of the most common reasons for this exception, even when just attempting a read.

Thanks, Eri. Yes, I did get a 0xC000005 exception.

It turns out the pointer was pointing to deallocated memory. The memory window shows 0xFEEEFEEE repeatedly (special value for deallocated heap memory) just after the deallocation, but later just before the dangling pointer is accessed, the memory window shows the question marks. Perhaps the memory page has been returned to the OS by then.

If anyone knows for sure what the question marks mean (or can give a reference), I'm still interested.
January 2nd, 2013, 08:26 AM
Igor Vartanov

Re: Question marks in memory window

All the process' memory space is virtual. And virtual memory page remains to be virtual one until VirtualAllocEx call instructs VMM to allocate and commit a physical memory page to the address space. So, the question marks indicate uncommitted memory. Reserved or not, don't know, but uncommitted for sure.
January 2nd, 2013, 09:57 AM
D_Drmmr

Re: Question marks in memory window

Quote:

Originally Posted by Igor Vartanov

All the process' memory space is virtual. And virtual memory page remains to be virtual one until VirtualAllocEx call instructs VMM to allocate and commit a physical memory page to the address space. So, the question marks indicate uncommitted memory. Reserved or not, don't know, but uncommitted for sure.

Thanks, Igor.
So, when I'm not calling VirtualAllocEx myself, the question marks could either indicate memory that was never allocated or memory that has been deallocated (and decommitted by the heap allocator).
If I see the value 0xFEEEFEEE repeatedly, I'm just lucky to know the memory has been deallocated, but hasn't been decommitted by the heap allocator yet.