Issues w/CRT on program exit?

[InvalidPointers]

Doing some work on the ol' memory manager this evening and recently I've been having read access violations occur after the actual program exit. The problematic line appears as follows, it appears to have to do with the value passed from my main function:

mainret = _tmain(__argc, _targv, _tenviron);
 

I'm no CRT expert, would anyone be able to give me some guidance as to what's going wrong here? I'm also having some difficulty figuring out a problem like this one would even occur. I can provide parts of my pool code upon request.

BTW I'm using MSVC2005.

[weaknessforcats]

mainret = _tmain(__argc, _targv, _tenviron);

If mainret is a return from _tmain(), then you are recursively calling your program. This probably continues until you blow the stack memory withall those _tmain() stack frames.

I need to see your _tmain() to see how you break the infinite recursion.

[InvalidPointers]

int main()
{
    CMemoryPool testingPool(65536, 1024);
    return 0;
}
 

Lovely, I know. Basic synopsis of what this is/means:
-I've obviously instantiated an instance of my memory pool class, the constructor there accepts two arguments: size of a block in the pool (64kb here) and the total number of blocks in the pool. (1024, for a grand total size of 64MB)

Constructor contents:
(It kind of butchered some of my formatting, sorry)

CMemoryPool::CMemoryPool(const size_t &_blockSize, const size_t &_defaultNumBlocksPerPage) : blockSize(_blockSize),                                                         defaultNumBlocksPerPage(_defaultNumBlocksPerPage), 
                                        defaultPageTotalCapacity(blockSize*defaultNumBlocksPerPage),
                                                        pageFirst(NULL), pageLast(NULL)
{
    cursorPtr = AllocateNewPage();
}
 

Essentially what happens there is that (obviously, I hope) cursorPtr, a general-purpose utility pointer used in ordering, searching/return and maintenance tasks gets set to the last pointer in the list of pages as a sort of safeguard and overhead reduction step. A new CMemoryPage class is created and then a new hunk of memory large enough to "contain" the number of blocks that you specified of the given size. (more on the quotation marks in a second)
Then the overall formatting and sectioning off of the physical page in memory begins. New 'block' objects are formed via regular new() commands, their individual constant pointers assigned to respective sections of the external block and finally everything is all set.

Page constructor code:

CMemoryPool::CMemoryPage::CMemoryPage(const size_t &_blockSize, const size_t &numBlocksInPage) : blockSize(_blockSize), 
                                                                                                        numTotalBlocks(numBlocksInPage),
                                                                                                        numFreeBlocks(numBlocksInPage)
{
    byte* pageLocation = (byte*)::operator new(blockSize*numBlocksInPage);    // allocate the correct amount of space-- size of a block times number of blocks
    blockFirst = new CMemoryBlock(pageLocation);    // take care of the first block here so we don't have to spend cycles on ifs throughout the for loop
    cursorBlock = blockFirst;
    pageLocation+=blockSize;
    for(size_t i=0; i<numBlocksInPage; pageLocation+=blockSize, i++)
    {
        cursorBlock->blockNext = new CMemoryBlock((void*)pageLocation);
        cursorBlock = cursorBlock->blockNext;
    }
    page = (void*)pageLocation;    // and tell the page object where it lives
}
 

I actually think the problem is with the loop at the end. I believe the second block int the page might not ever be initialized XD
Will update that after further examination.

EDIT: well I did find some problems, but actually the second thing did appear to execute correctly. It would seem, however, that pageLocation has flat-out ignored my instruction to increment itself by blockSize, despite the fact that it is *NOT* a constant. Rather baffling.

EDIT 2: Got it working using a fancy setup of address-of operators on pageLocation[0] and all that fun stuff. Highly annoying to have to spend time figuring out how to do that >:\ Still getting the errors though, have moves on to troubleshooting other parts of the pool.