This is a very, very bizzare problem I''m getting. I''m currently testing some image convertor code, and the bit I''m testing is an 8-bit windowed screen from an 8bit bitmap file. Fine, simple. BUT, get this, new() is failing, but only when I set my desktop to 256 colours. Anything else is fine, but put it in 8bit, and BOOM, new(() fails. _CrtCheckMemory() tells me there''s a bad node on the heap, which isn''t a lot of good to me as I''m not too sure how to fix that. Platform is Win2K SP2, PIII 866, 256MB ram, and an old 4MB S3 VirGE PCI vid card (don''t snigger, it''s only tempoary) I did some tracing etc... and found the heap allocations were failing due to exceptions in NTDLL.DLL Question is, anyone got a clue how the desktop colour depth is causing failures (access violations) in NTDLL.DLL? Waassaap!!

Ok, an update for you all to clarify a few things.

The reason I'm setting my desktop depth down to 256 is because it's a DX app, and I have to run in windowed mode so I can debug it properly. This means that to get a target image format of 8bit, I have to adjust the colour depth of the desktop down.

I've only just started the image convertor class, and so all I've done is the bit-depth independent straight-copy function. I just wanted to test it and get a visible result before I start the ones that are actually more effort to do.

The items I'm trying to allocate with new are classes, I just put the brackets in my message to show I meant the c++ new command.

Originally, the errors came when I was trying to create an instance of my CGraphic class. I wondered how this happened, as I hadn't altered the class in any way since my last debug build, and so I set breakpoints in the constructor(s), but they never got called.

I traced new into the crt source code, and came to HeapAlloc(), and after that is where the exceptions in NTDLL.DLL occur, so I created some dummy classes based on the graphic class, but without any of the functions, just the data to test things out. And these are what are still failing:

    class _CD2XGraphicDummyTest{protected:  int Height;          // Heigth of the graphic, in pixels  int Width;           // Width of the graphic, in pixels  int ColourDepth;     // The colour depth of the graphic  bitfield Flags;      // Miscellaneous info of object instance  // What the graphic is currently doing  enum State { Unloaded, Loading } CurrentState;};    

Again, all the allocations work fine in any other colour depth, just not 8 bit.

My suspicions are starting to think that somehow, something the debugger does is causing problems with the video driver's 8 bit code, but it's a wild guess.

I'm at a loss here, I've never had problems with the haep before. I was under the assumption that it would grow automatically to the programs requests, without needing any intervention, and as I have 256MB of ram + my swap file, I figured it'd be fine.

Waassaap!!

Edited by - mr_jrt on June 11, 2001 11:44:35 AM

Side thought:

Of course, this would be SO much easier to solve if I had the source to NTDLL.DLL.

Come on Bill, go open source!!!!!

Waassaap!!

Ok, I fixed it.

-Sorry for blaming you Bill-

Turns out it was a mistake in a previous malloc (which only runs in 8bit mode), where I allocated the memory for the pallette, I allocated 256 bytes, not 256 entries - my bad.

Hence when I filled it in with DDSurface->GetEntries(), I overwrote the heap, causing all the fun of the fair I got. Thanks go out to all for taking to take the time to try and help.

- mr_jrt

Waassaap!!