Crash of dgate1415.exe

Crash:

During a virtual server operation, version 14.15, native mysql

Faulting application dgate.exe, version 0.0.0.0, faulting module dgate.exe, version 0.0.0.0, fault address 0x00016a10.

Address from dgate.map:

0001:000168d0 ?RetrieveOn@@YAHPAVDICOMDataObject@@PAPAV1@PAPAVStandardStorage@@AAVRunTimeClassStorage@@PAVDICOMCommandObject@@PAV?$Array@PAVDICOMDataObject@@@@PAX@Z 004178d0 f dgate.obj

Marcel

Hi,

I looked in the debugger, and the crash seems to occur at the start of RetrieveOn, where it frees the thread data. I believe the crash may be related to a very slow response of a virtual server accessing a tape-backed NAS.

Marcel

We encounter this crash (too) regularly:

2010-01-21 14:07:11 Application Error Error (100) 1000 N/A PLAN02 Faulting application dgate.exe, version 0.0.0.0, faulting module dgate.exe, version 0.0.0.0, fault address 0x00016a10.

2010-01-20 11:24:15 Application Error Error (100) 1000 N/A PLAN02 Faulting application dgate.exe, version 0.0.0.0, faulting module dgate.exe, version 0.0.0.0, fault address 0x00016a10.

2010-01-14 08:27:17 Application Error Error (100) 1000 N/A PLAN02 Faulting application dgate.exe, version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.1830, fault address 0x0001f543.

2010-01-04 14:04:13 Application Error Error (100) 1000 N/A PLAN02 Faulting application dgate.exe, version 0.0.0.0, faulting module dgate.exe, version 0.0.0.0, fault address 0x00016a10.

Groetjes,

Peter

Hi,

Microsoft really has hidden the drwatson crash logs in xp but they still exist, as I discoverd last night:

C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson.

This what it showed:

eax=00000276 ebx=00000001 ecx=00000276 edx=0207b628 esi=015b78b8 edi=021ab9c7eip=00416a10 esp=028de798 ebp=00000276 iopl=0         nv up ei pl zr na po nccs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246function: dgate        004169ef e605             out     05,al        004169f1 0000             add     [eax],al        004169f3 894c2410         mov     [esp+0x10],ecx        004169f7 8b4618           mov     eax,[esi+0x18]        004169fa 3bc8             cmp     ecx,eax        004169fc 7d0e             jge     dgate+0x16a0c (00416a0c)        004169fe 8b54241c         mov     edx,[esp+0x1c]        00416a02 833c8a00         cmp     dword ptr [edx+ecx*4],0x0        00416a06 0f84b2050000     je      dgate+0x16fbe (00416fbe)        00416a0c 8b54241c         mov     edx,[esp+0x1c]FAULT ->00416a10 3b1c8a           cmp     ebx,[edx+ecx*4]   ds:0023:0207c000=????????        00416a13 7508             jnz     dgate+0x16a1d (00416a1d)

I always compile dgate.exe with the /Fa flag which creates an assembly lising of the module compiled. Aftre tedious searching in the assemby file around the nearest function of 00416a10 as indicated by map file, I found the code there, it corresponds to the following lines in dgate.cpp in function virtualServer2. I have indicated the fault and the error with an arrow.

// collect move requests together if possible (same series)	sops = (char *)malloc(66*ratd->NumToRead); sops[0]=0;	seriesnum = (int *)malloc(4*ratd->NumToRead); memset(seriesnum, 0, 4*ratd->NumToRead);	pats[0]=series[0]=studies[0] = 0;	j = 1;	if (ratd->NumToRead)		{		strcpy(pats   , ratd->pats   +0*66);		strcpy(studies, ratd->Studies+0*66);		strcpy(series , ratd->Series +0*66);		}	for (i=0; i<ratd->NumToRead; i++)		{		if (*(ratd->FullFilenames+i*1024)) continue;	// present		.....		}	// perform one or more c-move requests	sops[0]=0; j=1; k=0;	for (i=0; i<=ratd->NumToRead; i++)		{		// image not be to be retreived		if (i<ratd->NumToRead && seriesnum[i]==0) 			continue;		// image i is from a new series, send series belonging to image i-1-->FAULT		else if (j!=seriesnum[i] || i==ratd->NumToRead)			{

This shows how important it is to send me the drwtsn32.log file if you see a crash!

The corrected line is:

else if (i==ratd->NumToRead || j!=seriesnum[i])

If you check that i is out of range first then the out of range access to seriesnum does not occur. This bug causes a crash once a week during virtual server operation, if the out of range access is just on of the border of a 4K page and is detected.

Marcel