windbg dd command on hex adress giving ????question mark

what does below output in WINDBG mean,when I do dd command on hex address: a66e920

0:001> dd a66e920
00000000`0a66e920  ???????? ???????? ???????? ????????
00000000`0a66e930  ???????? ???????? ???????? ????????
00000000`0a66e940  ???????? ???????? ???????? ????????
00000000`0a66e950  ???????? ???????? ???????? ????????
00000000`0a66e960  ???????? ???????? ???????? ????????
00000000`0a66e970  ???????? ???????? ???????? ????????
00000000`0a66e980  ???????? ???????? ???????? ????????
00000000`0a66e990  ???????? ???????? ???????? ???????

Does this mean, hex adress is NULL ? I am new to windbg:

Below is our code snippet, renamed variables,function and structure name for privacy purpose, its crashing at point while accessing hb->buck_magic, as hb is invalid.

`#define BUCK_MAGIC 0x4255434b  /* "BUCK"   */

typedef struct {
   Card     buck_magic;
   Card     buck_size;
   Card     buck_used;
   List_obj **  buck_list;
} Bucket;



static Bucket *bucket_get( Ptr d )
{
   Bucket *hb;
   hb = *(Bucket **)d;
   
   if ( hb->buck_magic == BUCK_MAGIC ) return(hb);
   return(0);

}` 

latest frame output of crash:

0:001> 
00000000`012af220 char * d = 0x00000000`09630580 "???"
00000000`012af200 struct Bucket * hb = 0x00000000`0a103b80

0:001> dx -r1 ((code_bin!Bucket *)0xa103b80)
((code_bin!Bucket *)0xa103b80): 0xa103b80 [Type: Bucket *]
    [+0x000] buck_magic : Unable to read memory at Address 0xa103b80
    [+0x004] buck_size  : Unable to read memory at Address 0xa103b84
    [+0x008] buck_used  : Unable to read memory at Address 0xa103b88
    [+0x010] buck_list  : Unable to read memory at Address 0xa103b90
    
0:001> dx -r1 ((code_bin!char *)0x9630580)
((code_bin!char *)0x9630580): 0x9630580 : "???" [Type: char *]

0:001> dd 09630580
00000000`09630580  0a103b80 00000000 0a1253c0 00000000
00000000`09630590  09197bb0 00000000 06d7f980 00000000
00000000`096305a0  091afa30 00000000 091aeb30 00000000
00000000`096305b0  0a0ffbc0 00000000 091b10b0 00000000
00000000`096305c0  091a6f70 00000000 0a13bbc0 00000000
00000000`096305d0  0a13bbc0 00000000 0a17df10 00000000
00000000`096305e0  062b5570 00000000 000d760e 80000308
00000000`096305f0  00009aaf 00061aaf 00095aaf 000a9aaf
0:001> dp 09630580
00000000`09630580  00000000`0a103b80 00000000`0a1253c0
00000000`09630590  00000000`09197bb0 00000000`06d7f980
00000000`096305a0  00000000`091afa30 00000000`091aeb30
00000000`096305b0  00000000`0a0ffbc0 00000000`091b10b0
00000000`096305c0  00000000`091a6f70 00000000`0a13bbc0
00000000`096305d0  00000000`0a13bbc0 00000000`0a17df10
00000000`096305e0  00000000`062b5570 80000308`000d760e
00000000`096305f0  00061aaf`00009aaf 000a9aaf`00095aaf

0:001> dq 09630580
00000000`09630580  00000000`0a103b80 00000000`0a1253c0
00000000`09630590  00000000`09197bb0 00000000`06d7f980
00000000`096305a0  00000000`091afa30 00000000`091aeb30
00000000`096305b0  00000000`0a0ffbc0 00000000`091b10b0
00000000`096305c0  00000000`091a6f70 00000000`0a13bbc0
00000000`096305d0  00000000`0a13bbc0 00000000`0a17df10
00000000`096305e0  00000000`062b5570 80000308`000d760e
00000000`096305f0  00061aaf`00009aaf 000a9aaf`00095aaf
0:001> dp 0a103b80 
00000000`0a103b80  ????????`???????? ????????`????????
00000000`0a103b90  ????????`???????? ????????`????????
00000000`0a103ba0  ????????`???????? ????????`????????
00000000`0a103bb0  ????????`???????? ????????`????????
00000000`0a103bc0  ????????`???????? ????????`????????
00000000`0a103bd0  ????????`???????? ????????`????????
00000000`0a103be0  ????????`???????? ????????`????????
00000000`0a103bf0  ????????`???????? ????????`????????
0:001> dq 0a103b80 
00000000`0a103b80  ????????`???????? ????????`????????
00000000`0a103b90  ????????`???????? ????????`????????
00000000`0a103ba0  ????????`???????? ????????`????????
00000000`0a103bb0  ????????`???????? ????????`????????
00000000`0a103bc0  ????????`???????? ????????`????????
00000000`0a103bd0  ????????`???????? ????????`????????
00000000`0a103be0  ????????`???????? ????????`????????
00000000`0a103bf0  ????????`???????? ????????`????????
0:001> dd 0a103b80 
00000000`0a103b80  ???????? ???????? ???????? ????????
00000000`0a103b90  ???????? ???????? ???????? ????????
00000000`0a103ba0  ???????? ???????? ???????? ????????
00000000`0a103bb0  ???????? ???????? ???????? ????????
00000000`0a103bc0  ???????? ???????? ???????? ????????
00000000`0a103bd0  ???????? ???????? ???????? ????????
00000000`0a103be0  ???????? ???????? ???????? ????????
00000000`0a103bf0  ???????? ???????? ???????? ????????

The question marks indicate that the memory is not available.

For crash dumps: the memory might not be included in the crash dump, depending on the MINIDUMP_TYPE that was used to create the crash dump. E.g. Procdump has an option ( -mp) to exclude memory regions larger than 512 MB. If you assume that's the case, create crash dumps with full memory.

For live debugging: there was never a VirtualAlloc() call to the operating system that returned this portion of memory. Or, the memory was allocated but has been VirtualFree()d, so it's no longer available. If the program would access the memory in a read or write operation, an access violation (AV) would occur.

The question marks are not equivalent to NULL values. A null pointer value at that address would be 00000000 (32 bit) or 00000000'00000000 (64 bit).

If you have a pointer that points to such memory, it might also be that you're building a C++ program in Release build, which may leave pointers with some garbage if you never initialize them ("bogus pointer"). In debug mode, they would be initialized with some memory pattern.

Side note: if you're investigating pointers, using dp ("dump pointer sized data") is preferred over dd (32 bit) or dq (64 bit).