just so you know, i was using 5.0.1.6. but here's a little crash report:
Quote:
Access violation when executing [77E7D961]
stack:
0012FF74 00476FE1 RETURN to 00476FE1 from 77E7D961
0012FF78 00476FC8 ASCII "DvdIdlePro"
0012FF7C 0090D818
0012FF80 7FFD7BF8
0012FF84 0045C013 RETURN to 0045C013 from 0045C014
0012FF88 0012FF9C
0012FF8C 00400000 00400000
00476FD7 PUSH 00476FC8 ; ASCII "DvdIdlePro"
00476FDC CALL 77E7D961 ; offending caller
00476FE1 MOV ESI,EAX
00476FE3 PUSH 1
00476FE5 PUSH EAX
00476FE6 CALL 77E7B332
00476FEB CALL EAX
00476FED POPAD
00476FEE PUSH DWORD PTR SS:[EBP+9D5]
00476FF4 PUSH 0045C03F
00476FF9 RETN
00476FC8 44 76 64 49 64 6C 65 50 72 6F 00 00 00 00 60 68 DvdIdlePro....`h
00476FD8 C8 6F 47 00 E8 80 69 A0 77 8B F0 6A 01 50 E8 47 萶G.鑰i爓嬸jP鐶
00476FE8 43 A0 77 FF D0 61 FF B5 D5 09 00 00 68 3F C0 45 C爓衋嫡...h?繣
00476FF8 00 C3 00 00 00 00 00 00 62 72 69 74 65 64 72 65 .?.....britedre
00477008 61 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 am..............
|
the way to fix this would be to call a pointer address to whatever api you're trying to use, instead of a direct call. this would fix the issue i'm sure. and, yes, this is still on my win2k system
if they went back to the older aspr, that's a good thing for them and their customers. i don't like the way the new aspr runs (which is too slow). programmers who use these protections should always opt for speed cuz even when they use these 'advanced' options it doesn't make it unbreakable for those of us who know the ways around this stuff. if they opt for a slower more heavily protected app you should expect complaints from your customers about sluggish performance. just my 2 cents.