#gpf in aaplay
6 messages in this thread
this is the drwatson log file of a GPF wich we get on some machine playing an
FLI with AAPLAY under VB.
Some suggestion ?
==>
Start Dr. Watson 0.80 – Sun Oct 9 14:46:21 1994
Stop Dr. Watson 0.80 – Sun Oct 9 14:51:10 1994
Start Dr. Watson 0.80 – Thu Apr 20 13:51:06 1995
****************************************************************************
Dr. Watson 0.80 Failure Report – Thu Apr 20 14:02:07 1995
TRENDS had a 'Exceed Segment Bounds (Read)' fault at AAPLAY 1:0244
$tag$TRENDS$Exceed Segment Bounds (Read)$AAPLAY 1:0244$lodsb$Thu Apr 20 14:02:07
1995
CPU Registers (regs)
ax=0028 bx=02ec cx=0067 dx=00a9 si=08e5 di=003c
ip=0244 sp=713c bp=7146 O- D- I+ S- Z- A- P- C-
cs = 1a87 807270a0:9f5f Code Ex/R
ss = 1ea7 80886e40:829f Data R/W
ds = 1f77 806e1500:08df Data R/W
es = 1f47 806e3640:065f Data R/W
CPU 32 bit Registers (32bit)
eax = 00000028 ebx = 000002ec ecx = 00000067 edx = 000000a9
esi = 000008e5 edi = 0000003c ebp = 00007146 esp = 8001712c
fs = 0000 0:0000 Null Ptr
gs = 0000 0:0000 Null Ptr
eflag = 00000202
System Info (info)
Windows version 3.10
Retail build
Windows Build 3.1
Username L. SPIRLET
Organization S.P.R.L. INDUMET
System Free Space 13992288
Stack base 9004, top 29334, lowest 26478, size 20330
System resources: USER: 81% free, seg 0607 GDI: 78% free, seg 044f
LargestFree 11927552, MaxPagesAvail 2912, MaxPagesLockable 1036
TotalLinear 3932, TotalUnlockedPages 1043, FreePages 230
TotalPages 1339, FreeLinearSpace 2945, SwapFilePages 5110
Page Size 4096
5 tasks executing.
WinFlags –
Math coprocessor
80486
Enhanced mode
Protect mode
Stack Dump (stack)
Stack Frame 0 is AAPLAY 1:0244 ss:bp 1ea7:7146
1a87:023d 73 4f jae short 028e
1a87:023f ac lodsb
1a87:0240 8b c8 mov cx, ax
1a87:0242 e3 28 jcxz short 026c
(AAPLAY:1:0244)
1a87:0244 ac lodsb
1a87:0245 0a c0 or al, al
1a87:0247 74 03 jz short 024c
1a87:0249 83 c3 04 add bx, 04
Stack Frame 1 is AAPLAY 1:7465 ss:bp 1ea7:718c
1a87:745f 52 push dx
1a87:7460 90 nop
1a87:7461 0e push cs
1a87:7462 e8 8d29 call near 018e
(AAPLAY:1:7465)
1a87:7465 83 c4 14 add sp, 14
1a87:7468 89 56 e8 mov [bp+e8], dx
1a87:746b 89 46 e6 mov [bp+e6], ax
1a87:746e 52 push dx
Stack Frame 2 is AAPLAY 1:6edb ss:bp 1ea7:71ba
Stack Frame 3 is AAPLAY 1:359b ss:bp 1ea7:7214
Stack Frame 4 is USER 1:27bb ss:bp 1ea7:722e
Stack Frame 5 is VBRUN300 22:017c ss:bp 1ea7:7262
Stack Frame 6 is VBRUN300 22:0067 ss:bp 1ea7:7270
Stack Frame 7 is VBRUN300 58:2225 ss:bp 1ea7:7282
Stack Frame 8 is VBRUN300 58:1492 ss:bp 1ea7:7294
System Tasks (tasks)
Task DRWATSON, Handle 1ccf, Flags 0001, Info 26864 03-10-92 12:00
FileName D:\WINDOWS\DRWATSON.EXE
Task OCRAWARE, Handle 131f, Flags 0001, Info 37904 07-09-94 17:10
FileName D:\WORDSCAN\OCRAWARE.EXE
Task PROGMAN, Handle 0497, Flags 0001, Info 116336 03-10-92 12:00
FileName D:\WINDOWS\PROGMAN.EXE
Task FAXITSCH, Handle 14af, Flags 0001, Info 12496 07-30-92 0:14
FileName D:\WINDOWS\FAXITSCH.EXE
Task TRENDS, Handle 1eef, Flags 0001, Info 378917 03-03-95 15:18
FileName E:\TRENDS\TRENDS.EXE
1> startup trends.exe
Stop Dr. Watson 0.80 – Thu Apr 20 14:07:47 1995
<<his is the drwatson log file of a GPF wich we get on some machine playing an
FLI with AAPLAY under VB.
Some suggestion ?>>
It does appear that TRENDS is causing a conflict with AAPLAY. First try running
Windows in a stripped environment. That would be FILES, BUFFERS, and HIMEM.SYS
in the CONFIG.SYS, and PATH and PROMPT in the AUTOEXEC.BAT. No other memory
managers, deveice drivers or anything. Does the error continue? If yes, also
try starting Windows with the command switches to turn things off. For example:
Win /x would start windows and exclude all the memory
Win /n would start Windows for workgroups without the nework
Type WIN /? at the dos prompt to see the valid selections for your version of
Windows.
-Brian
Brian:
The stability of AAPLAY.DLL has always been a problem in Windows. I realize
that the official explanation of GPF's is that there is a problem with the
user's Windows environment, but there are many circumstances where buggy
programs an also cause them (I know, I've accidentally written some :-o). For
example, improperly allocating and deallocating memory in the DLL subroutine
will cause a GPF.
There are also several documented bugs with the VBPLAY.VBX (which uses
AAPLAY.DLL). Is Autodesk planning to update these libraries to more stable
versions soon?
Thank you in advance,
Steve Peer
<<here are also several documented bugs with the VBPLAY.VBX (which uses
AAPLAY.DLL). Is Autodesk planning to update these libraries to more stable
versions soon?>>
I am sorry, but I am not allowed to talk about future releases of Autodesk
software or developers kits.
However, I can say that we have had many requests to update the developers kit,
and user requests are what drives new development. Also, with the new release
of Animator Studio…..
-Brian
>>I am sorry, but I am not allowed to talk about future releases of Autodesk
software or developers kits.
Brian:
At the very least, I appreciate your reply to my questions. However, I have
been a reseller/user of Autodesk products for many years now, and have seen the
same patterns repeated over and over again. These patterns include:
1) New releases of products that have not been fully beta-tested. (i.e.
problems with the new Animator Studio)
2) A reluctance to admit that there are problems with existing software, such
as VBPLAY.VBX
I want to stress that I believe that Autodesk is a superb organization,
demonstrating true innovation in their product line. It is VITAL for Autodesk
not to miss the opportunity to establish the FLI/FLC format as a widely
accepted standard for multimedia developers. The format offers much for
computer-generated animations that Video for Windows and QuickTime do not. This
will NOT happen if many systems cannot use AAPLAY.DLL or VBPLAY.VBX because of
GPF's.
I wish you, and your company all the best in the months to come.
Steve Peer
Steve,
Thank you for your comments. We recognize there will always be areas for
improvement, and appreciate constructive criticism. I have forwarded your
comments to the product manager as well.
-Brian