Possibly tough question to answer
Well I used to have those errors, but a new HDD and motherboard fixed that. Thank god for extended warranty. Although it wont be anything that drastic as it''s only your program
Ah - the IRQL_NOT_LESS_OR_EQUAL message...
I have seen this a couple of times and I *think* (IIRC) that this happens when a system process tries to access memory which it does not own. Check on Google as I would expect you'll find more info. there...
NOTE: Buggy driver implementation can cause this error condition.
Regards,
Sharky
EDIT: check this link if you haven't already
---
#define _WEBSITE
Sharky's Coding Corner
#endif
---
[edited by - Sharky on May 5, 2003 7:12:49 PM]
I have seen this a couple of times and I *think* (IIRC) that this happens when a system process tries to access memory which it does not own. Check on Google as I would expect you'll find more info. there...
NOTE: Buggy driver implementation can cause this error condition.
Regards,
Sharky
EDIT: check this link if you haven't already
---
#define _WEBSITE
Sharky's Coding Corner
#endif
---
[edited by - Sharky on May 5, 2003 7:12:49 PM]
IRQL_NOT_LESS_OR_EQUAL is a very common problem in drivers and happens when a driver is using an improper address, which is usually an errant pointer. This gets triggered when a thread accesses pageable memory when the interrupt request level is too high. In english this basically means that somewhere in the driver routine there is access to pageable memory when the system has it''s IRQL to high. The reason this happens is because the routine can get called away and the memory paged causing a "BadThing" so the system bugchecks to keep the system from becoming unstable.
The stack trace should give you an idea of the offending routine. The first parameter is the virtual address of the memory referenced. The second parameter is the IRQL level at whcih access was attempted. The third parameter indicates if it was a read (0) or write (1) operation. The fourth parameter is the address in he code that referenced the memory.
This is most likely a driver or DX issue unless your app somehow managed to overwrite something in the driver routines (interesting, that would indicate a possible buffer overflow situation...) which is pretty unlikely. Still, if you are able to run just about any comercial game without issue you have to think whatever you are sending to the driver is causing it to puke.
The stack trace should give you an idea of the offending routine. The first parameter is the virtual address of the memory referenced. The second parameter is the IRQL level at whcih access was attempted. The third parameter indicates if it was a read (0) or write (1) operation. The fourth parameter is the address in he code that referenced the memory.
This is most likely a driver or DX issue unless your app somehow managed to overwrite something in the driver routines (interesting, that would indicate a possible buffer overflow situation...) which is pretty unlikely. Still, if you are able to run just about any comercial game without issue you have to think whatever you are sending to the driver is causing it to puke.
Oh, brilliant, a real flamewar! IMHO, DirectX is crappy, and OpenGL is the only real graphics API! Ahahahahahahahahahaha! Nah, I'm just kidding. Anyway, my Phalanx anti-missile Gatling gun beats your flamethrower...
Coding Stuff -> [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff -> [ Evil T-Shirts | Stick-Based Comedy | You're Already Here | The Best Film Reviews ]
[edited by - iNsAn1tY on May 9, 2003 4:00:28 PM]
Coding Stuff -> [ iNsAn1tY Games | DarkVertex | How To Do CSG | Direct3D Vs. OpenGL | Google ]
Fun Stuff -> [ Evil T-Shirts | Stick-Based Comedy | You're Already Here | The Best Film Reviews ]
[edited by - iNsAn1tY on May 9, 2003 4:00:28 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement