WineHQ 6.0 - Ubuntu 20.04 - Add USBSTOR.SYS driver support - ubuntu-20.04

I have launched this program
wine 'C:\Program Files (x86)\Rufus\rufus.exe' 2> rufus.log
and I have obtained this log:
0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0034:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0064:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0064:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
006c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
006c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
INTEL-MESA: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0
002c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
002c:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0024:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
0024:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00c0:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00c0:fixme:font:get_name_record_codepage encoding 20 not handled, platform 1.
00f8:err:ole:com_get_class_object class {ea502722-a23d-11d1-a7d3-0000f87571e3} not registered
00f8:err:ole:com_get_class_object no class object {ea502722-a23d-11d1-a7d3-0000f87571e3} could be created for context 0x1
0058:fixme:mountmgr:mountmgr_ioctl ioctl 6d003c not supported
0024:fixme:oleacc:AccPropServices_ClearHwndProps (000100D2 4294967292 0 0093EDC0 1)
0024:fixme:oleacc:AccPropServices_SetHwndPropStr (000100D2 4294967292 0 {c3a6921b-4a99-44f1-bca6-61187052c431} L"Save to VHD")
0024:fixme:oleacc:AccPropServices_ClearHwndProps (000200D4 4294967292 0 0093EDC0 1)
0024:fixme:oleacc:AccPropServices_SetHwndPropStr (000200D4 4294967292 0 {c3a6921b-4a99-44f1-bca6-61187052c431} L"Compute image checksums")
0024:fixme:oleacc:AccPropServices_ClearHwndProps (000100B4 4294967292 0 0093EE50 1)
0024:fixme:oleacc:AccPropServices_SetHwndPropStr (000100B4 4294967292 0 {c3a6921b-4a99-44f1-bca6-61187052c431} L"Number of passes")
0024:fixme:oleacc:AccPropServices_ClearHwndProps (00010096 4294967292 0 0093EE50 1)
0024:fixme:oleacc:AccPropServices_SetHwndPropStr (00010096 4294967292 0 {c3a6921b-4a99-44f1-bca6-61187052c431} L"Disk ID")
0024:fixme:explorerframe:taskbar_list_SetProgressState iface 01737C10, hwnd 00010054, flags 2 stub!
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=00030044 wParam=30044 lParam=3
0024:fixme:oleacc:AccPropServices_ClearHwndProps (000300D6 4294967292 0 0093ED40 1)
0024:fixme:oleacc:AccPropServices_SetHwndPropStr (000300D6 4294967292 0 {c3a6921b-4a99-44f1-bca6-61187052c431} L"advanced drive properties")
0024:fixme:oleacc:AccPropServices_ClearHwndProps (000100D8 4294967292 0 0093ED40 1)
0024:fixme:oleacc:AccPropServices_SetHwndPropStr (000100D8 4294967292 0 {c3a6921b-4a99-44f1-bca6-61187052c431} L"advanced format options")
0024:fixme:oleacc:AccPropServices_ClearHwndProps (000100DA 4294967292 0 0093ED40 1)
0024:fixme:oleacc:AccPropServices_SetHwndPropStr (000100DA 4294967292 0 {c3a6921b-4a99-44f1-bca6-61187052c431} L"Multiple buttons")
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100E0 wParam=100e0 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100E2 wParam=100e2 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100E4 wParam=100e4 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100E6 wParam=100e6 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100E8 wParam=100e8 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100EA wParam=100ea lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100EC wParam=100ec lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100EE wParam=100ee lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100F0 wParam=100f0 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100F2 wParam=100f2 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100F4 wParam=100f4 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100F6 wParam=100f6 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100F8 wParam=100f8 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100FA wParam=100fa lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100FC wParam=100fc lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=000100FE wParam=100fe lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=00010100 wParam=10100 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=00010102 wParam=10102 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=00010104 wParam=10104 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=00010106 wParam=10106 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=00010108 wParam=10108 lParam=3
0024:fixme:tooltips:TOOLTIPS_NotifyFormat hwnd=0001010A wParam=1010a lParam=3
0024:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0093EA30 "USBSTOR" 0x00000102: stub
0024:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0093EA34 "RTSUER" 0x00000102: stub
0024:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0093EA38 "CMIUCR" 0x00000102: stub
0024:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0093EA3C "EUCR" 0x00000102: stub
0024:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0093EA40 "UASPSTOR" 0x00000102: stub
0024:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0093EA44 "VUSBSTOR" 0x00000102: stub
0024:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0093EA48 "ETRONSTOR" 0x00000102: stub
0024:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0093EA4C "ASUSSTPT" 0x00000102: stub
0024:fixme:msg:ChangeWindowMessageFilterEx 00010054 233 1 00000000
0024:fixme:msg:ChangeWindowMessageFilterEx 00010054 4a 1 00000000
0024:fixme:msg:ChangeWindowMessageFilterEx 00010054 49 1 00000000
0024:fixme:font:ExtTextOutW flags ETO_NUMERICSLOCAL | ETO_NUMERICSLATIN unimplemented
00fc:fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT/DATA_SEND_TIMEOUT 3500
00fc:fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT/DATA_SEND_TIMEOUT 3500
00fc:fixme:wininet:InternetSetOptionW Option 148 STUB
00fc:fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT/DATA_SEND_TIMEOUT 3500
00fc:fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT/DATA_SEND_TIMEOUT 3500
00fc:fixme:wininet:InternetSetOptionW Option 148 STUB
On Windows the usb are seen correctly by Rufus and going into the driver information I saw that the usb made use of the USBSTOR.SYS and usbstor.inf driver, not present on WineHQ (It goes without saying that the symlink to the drive was done correctly by Wine, so none of the guides already seen on the internet are useful to me.):
0024:fixme:setupapi:CM_Get_Device_ID_List_SizeA 0093EA30 "USBSTOR" 0x00000102: stub
How can I correctly install the USBSTOR driver in WineHQ, implementing the relative service?

Related

Creating share of one variable in Top/Bottom 10 of another variable

I have 5 variables: nacional , nacional=1 for natives , nacional=0 for non-natives, FirmsID: NPC_FIC, Establsihmenti;s ID: ESTAB_ID, Occupation codes: CCPCodes and skill ratio: sk_ratio.I am going to compute the share of immigrants in Top 10 and Bottom 10 occupations. Since each firm has more than one establishment more often makes the solution tricky. Any help are apprecited.
input float nacioanal double(NPC_FIC ESTAB_ID) float CCPCodes double sk_ratio
1 500988754 100861 1114 4.359499
1 501950749 893218 1114 4.359499
1 500988750 990861 6914 2.309491
1 501951290 125210 1114 4.359499
1 500988760 100861 1141 5.459470
1 502000740 -820100 1114 4.359499
0 500988762 880861 7514 66.359409
1 500988754 100861 1114 4.359499
1 577988759 210869 4116 6.059120
1 500988092 670869 3216 10.059785
I used 'extremes sk_ratio CCPCodes, n(10)' to make top/bottom 10 but because of repeated valules I could not go futher.

DPC_WATCHDOG_VIOLATION (133/1) Potentially related to NdisFIndicateReceiveNetBufferLists?

We have a NDIS LWF driver, and on a single machine we get a DPC_WATCHDOG_VIOLATION 133/1 bugcheck when they try to connect to their VPN to connect to the internet. This could be related to our NdisFIndicateReceiveNetBufferLists, as the IRQL is raised to DISPATCH before calling it (and obviously lowered to whatever it was afterward), and that does appear in the output of !dpcwatchdog shown below. This is done due to a workaround for another bug explained here:
IRQL_UNEXPECTED_VALUE BSOD after NdisFIndicateReceiveNetBufferLists?
Now this is the bugcheck:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000001, The system cumulatively spent an extended period of time at
DISPATCH_LEVEL or above. The offending component can usually be
identified with a stack trace.
Arg2: 0000000000001e00, The watchdog period.
Arg3: fffff805422fb320, cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, which contains
additional information regarding the cumulative timeout
Arg4: 0000000000000000
STACK_TEXT:
nt!KeBugCheckEx
nt!KeAccumulateTicks+0x1846b2
nt!KiUpdateRunTime+0x5d
nt!KiUpdateTime+0x4a1
nt!KeClockInterruptNotify+0x2e3
nt!HalpTimerClockInterrupt+0xe2
nt!KiCallInterruptServiceRoutine+0xa5
nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
nt!KiInterruptDispatchNoLockNoEtw+0x37
nt!KxWaitForSpinLockAndAcquire+0x2c
nt!KeAcquireSpinLockAtDpcLevel+0x5c
wanarp!WanNdisReceivePackets+0x4bb
ndis!ndisMIndicateNetBufferListsToOpen+0x141
ndis!ndisMTopReceiveNetBufferLists+0x3f0e4
ndis!ndisCallReceiveHandler+0x61
ndis!ndisInvokeNextReceiveHandler+0x1df
ndis!NdisMIndicateReceiveNetBufferLists+0x104
ndiswan!IndicateRecvPacket+0x596
ndiswan!ApplyQoSAndIndicateRecvPacket+0x20b
ndiswan!ProcessPPPFrame+0x16f
ndiswan!ReceivePPP+0xb3
ndiswan!ProtoCoReceiveNetBufferListChain+0x442
ndis!ndisMCoIndicateReceiveNetBufferListsToNetBufferLists+0xf6
ndis!NdisMCoIndicateReceiveNetBufferLists+0x11
raspptp!CallIndicateReceived+0x210
raspptp!CallProcessRxNBLs+0x199
ndis!ndisDispatchIoWorkItem+0x12
nt!IopProcessWorkItem+0x135
nt!ExpWorkerThread+0x105
nt!PspSystemThreadStartup+0x55
nt!KiStartSystemThread+0x28
SYMBOL_NAME: wanarp!WanNdisReceivePackets+4bb
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: wanarp
IMAGE_NAME: wanarp.sys
And this following is the output of !dpcwatchdog, but I still can't find what is causing this bugcheck, and can't find which function is consuming too much time in DISPATCH level which is causing this bugcheck. Although I think this could be related to some spin locking done by wanarp? Could this be a bug with wanarp? Note that we don't use any spinlocking in our driver, and us raising the IRQL should not cause any issue as it is actually very common for indication in Ndis to be done at IRQL DISPATCH.
So How can I find the root cause of this bugcheck? There are no other third party LWF in the ndis stack.
3: kd> !dpcwatchdog
All durations are in seconds (1 System tick = 15.625000 milliseconds)
Circular Kernel Context Logger history: !logdump 0x2
DPC and ISR stats: !intstats /d
--------------------------------------------------
CPU#0
--------------------------------------------------
Current DPC: No Active DPC
Pending DPCs:
----------------------------------------
CPU Type KDPC Function
dpcs: no pending DPCs found
--------------------------------------------------
CPU#1
--------------------------------------------------
Current DPC: No Active DPC
Pending DPCs:
----------------------------------------
CPU Type KDPC Function
1: Normal : 0xfffff80542220e00 0xfffff805418dbf10 nt!PpmCheckPeriodicStart
1: Normal : 0xfffff80542231d40 0xfffff8054192c730 nt!KiBalanceSetManagerDeferredRoutine
1: Normal : 0xffffbd0146590868 0xfffff80541953200 nt!KiEntropyDpcRoutine
DPC Watchdog Captures Analysis for CPU #1.
DPC Watchdog capture size: 641 stacks.
Number of unique stacks: 1.
No common functions detected!
The captured stacks seem to indicate that only a single DPC or generic function is the culprit.
Try to analyse what other processors were doing at the time of the following reference capture:
CPU #1 DPC Watchdog Reference Stack (#0 of 641) - Time: 16 Min 17 Sec 984.38 mSec
# RetAddr Call Site
00 fffff805418d8991 nt!KiUpdateRunTime+0x5D
01 fffff805418d2803 nt!KiUpdateTime+0x4A1
02 fffff805418db1c2 nt!KeClockInterruptNotify+0x2E3
03 fffff80541808a45 nt!HalpTimerClockInterrupt+0xE2
04 fffff805419fab9a nt!KiCallInterruptServiceRoutine+0xA5
05 fffff805419fb107 nt!KiInterruptSubDispatchNoLockNoEtw+0xFA
06 fffff805418a9a9c nt!KiInterruptDispatchNoLockNoEtw+0x37
07 fffff805418da3cc nt!KxWaitForSpinLockAndAcquire+0x2C
08 fffff8054fa614cb nt!KeAcquireSpinLockAtDpcLevel+0x5C
09 fffff80546ba1eb1 wanarp!WanNdisReceivePackets+0x4BB
0a fffff80546be0b84 ndis!ndisMIndicateNetBufferListsToOpen+0x141
0b fffff80546ba7ef1 ndis!ndisMTopReceiveNetBufferLists+0x3F0E4
0c fffff80546bddfef ndis!ndisCallReceiveHandler+0x61
0d fffff80546ba4a94 ndis!ndisInvokeNextReceiveHandler+0x1DF
0e fffff8057c32d17e ndis!NdisMIndicateReceiveNetBufferLists+0x104
0f fffff8057c30d6c7 ndiswan!IndicateRecvPacket+0x596
10 fffff8057c32d56b ndiswan!ApplyQoSAndIndicateRecvPacket+0x20B
11 fffff8057c32d823 ndiswan!ProcessPPPFrame+0x16F
12 fffff8057c308e62 ndiswan!ReceivePPP+0xB3
13 fffff80546c5c006 ndiswan!ProtoCoReceiveNetBufferListChain+0x442
14 fffff80546c5c2d1 ndis!ndisMCoIndicateReceiveNetBufferListsToNetBufferLists+0xF6
15 fffff8057c2b0064 ndis!NdisMCoIndicateReceiveNetBufferLists+0x11
16 fffff8057c2b06a9 raspptp!CallIndicateReceived+0x210
17 fffff80546bd9dc2 raspptp!CallProcessRxNBLs+0x199
18 fffff80541899645 ndis!ndisDispatchIoWorkItem+0x12
19 fffff80541852b65 nt!IopProcessWorkItem+0x135
1a fffff80541871d25 nt!ExpWorkerThread+0x105
1b fffff80541a00778 nt!PspSystemThreadStartup+0x55
1c ---------------- nt!KiStartSystemThread+0x28
--------------------------------------------------
CPU#2
--------------------------------------------------
Current DPC: No Active DPC
Pending DPCs:
----------------------------------------
CPU Type KDPC Function
2: Normal : 0xffffbd01467f0868 0xfffff80541953200 nt!KiEntropyDpcRoutine
DPC Watchdog Captures Analysis for CPU #2.
DPC Watchdog capture size: 641 stacks.
Number of unique stacks: 1.
No common functions detected!
The captured stacks seem to indicate that only a single DPC or generic function is the culprit.
Try to analyse what other processors were doing at the time of the following reference capture:
CPU #2 DPC Watchdog Reference Stack (#0 of 641) - Time: 16 Min 17 Sec 984.38 mSec
# RetAddr Call Site
00 fffff805418d245a nt!KeClockInterruptNotify+0x453
01 fffff80541808a45 nt!HalpTimerClockIpiRoutine+0x1A
02 fffff805419fab9a nt!KiCallInterruptServiceRoutine+0xA5
03 fffff805419fb107 nt!KiInterruptSubDispatchNoLockNoEtw+0xFA
04 fffff805418a9a9c nt!KiInterruptDispatchNoLockNoEtw+0x37
05 fffff805418a9a68 nt!KxWaitForSpinLockAndAcquire+0x2C
06 fffff8054fa611cb nt!KeAcquireSpinLockRaiseToDpc+0x88
07 fffff80546ba1eb1 wanarp!WanNdisReceivePackets+0x1BB
08 fffff80546be0b84 ndis!ndisMIndicateNetBufferListsToOpen+0x141
09 fffff80546ba7ef1 ndis!ndisMTopReceiveNetBufferLists+0x3F0E4
0a fffff80546bddfef ndis!ndisCallReceiveHandler+0x61
0b fffff80546be3a81 ndis!ndisInvokeNextReceiveHandler+0x1DF
0c fffff80546ba804e ndis!ndisFilterIndicateReceiveNetBufferLists+0x3C611
0d fffff8054e384d77 ndis!NdisFIndicateReceiveNetBufferLists+0x6E
0e fffff8054e3811a9 ourdriver+0x4D70
0f fffff80546ba7d40 ourdriver+0x11A0
10 fffff8054182a6b5 ndis!ndisDummyIrpHandler+0x100
11 fffff80541c164c8 nt!IofCallDriver+0x55
12 fffff80541c162c7 nt!IopSynchronousServiceTail+0x1A8
13 fffff80541c15646 nt!IopXxxControlFile+0xC67
14 fffff80541a0aab5 nt!NtDeviceIoControlFile+0x56
15 ---------------- nt!KiSystemServiceCopyEnd+0x25
--------------------------------------------------
CPU#3
--------------------------------------------------
Current DPC: No Active DPC
Pending DPCs:
----------------------------------------
CPU Type KDPC Function
dpcs: no pending DPCs found
Target machine version: Windows 10 Kernel Version 19041 MP (4 procs)
Also note that we also pass the NDIS_RECEIVE_FLAGS_DISPATCH_LEVEL flag to the NdisFIndicateReceiveNetBufferLists, if the current IRQL is dispatch.
Edit1:
This is also the output of !locks and !qlocks and !ready, And the contention count on one of the resources is 49135, is this normal or too high? Could this be related to our issue? The threads that are waiting on it or own it are for normal processes such as chrome, csrss, etc.
3: kd> !kdexts.locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks.
Resource # nt!ExpTimeRefreshLock (0xfffff80542219440) Exclusively owned
Contention Count = 17
Threads: ffffcf8ce9dee640-01<*>
KD: Scanning for held locks.....
Resource # 0xffffcf8cde7f59f8 Shared 1 owning threads
Contention Count = 62
Threads: ffffcf8ce84ec080-01<*>
KD: Scanning for held locks...............................................................................................
Resource # 0xffffcf8ce08d0890 Exclusively owned
Contention Count = 49135
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 6
Threads: ffffcf8cf18e3080-01<*> ffffcf8ce3faf080-01
Threads Waiting On Exclusive Access:
ffffcf8ceb6ce080 ffffcf8ce1d20080 ffffcf8ce77f1080 ffffcf8ce92f4080
ffffcf8ce1d1f0c0 ffffcf8ced7c6080
KD: Scanning for held locks.
Resource # 0xffffcf8ce08d0990 Shared 1 owning threads
Threads: ffffcf8cf18e3080-01<*>
KD: Scanning for held locks.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Resource # 0xffffcf8ceff46350 Shared 1 owning threads
Threads: ffffcf8ce6de8080-01<*>
KD: Scanning for held locks......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Resource # 0xffffcf8cf0cade50 Exclusively owned
Contention Count = 3
Threads: ffffcf8ce84ec080-01<*>
KD: Scanning for held locks.........................
Resource # 0xffffcf8cf0f76180 Shared 1 owning threads
Threads: ffffcf8ce83dc080-02<*>
KD: Scanning for held locks.......................................................................................................................................................................................................................................................
Resource # 0xffffcf8cf1875cb0 Shared 1 owning threads
Contention Count = 3
Threads: ffffcf8ce89db040-02<*>
KD: Scanning for held locks.
Resource # 0xffffcf8cf18742d0 Shared 1 owning threads
Threads: ffffcf8cee5e1080-02<*>
KD: Scanning for held locks....................................................................................
Resource # 0xffffcf8cdceeece0 Shared 2 owning threads
Contention Count = 4
Threads: ffffcf8ce3a1c080-01<*> ffffcf8ce5625040-01<*>
Resource # 0xffffcf8cdceeed48 Shared 1 owning threads
Threads: ffffcf8ce5625043-02<*> *** Actual Thread ffffcf8ce5625040
KD: Scanning for held locks...
Resource # 0xffffcf8cf1d377d0 Exclusively owned
Threads: ffffcf8cf0ff3080-02<*>
KD: Scanning for held locks....
Resource # 0xffffcf8cf1807050 Exclusively owned
Threads: ffffcf8ce84ec080-01<*>
KD: Scanning for held locks......
245594 total locks, 13 locks currently held
3: kd> !qlocks
Key: O = Owner, 1-n = Wait order, blank = not owned/waiting, C = Corrupt
Processor Number
Lock Name 0 1 2 3
KE - Unused Spare
MM - Unused Spare
MM - Unused Spare
MM - Unused Spare
CC - Vacb
CC - Master
EX - NonPagedPool
IO - Cancel
CC - Unused Spare
IO - Vpb
IO - Database
IO - Completion
NTFS - Struct
AFD - WorkQueue
CC - Bcb
MM - NonPagedPool
3: kd> !ready
KSHARED_READY_QUEUE fffff8053f1ada00: (00) ****------------------------------------------------------------
SharedReadyQueue fffff8053f1ada00: No threads in READY state
Processor 0: No threads in READY state
Processor 1: Ready Threads at priority 15
THREAD ffffcf8ce9dee640 Cid 2054.2100 Teb: 000000fab7bca000 Win32Thread: 0000000000000000 READY on processor 1
Processor 2: No threads in READY state
Processor 3: No threads in READY state
3: kd> dt nt!_ERESOURCE 0xffffcf8ce08d0890
+0x000 SystemResourcesList : _LIST_ENTRY [ 0xffffcf8c`e08d0610 - 0xffffcf8c`e08cf710 ]
+0x010 OwnerTable : 0xffffcf8c`ee6e8210 _OWNER_ENTRY
+0x018 ActiveCount : 0n1
+0x01a Flag : 0xf86
+0x01a ReservedLowFlags : 0x86 ''
+0x01b WaiterPriority : 0xf ''
+0x020 SharedWaiters : 0xffffae09`adcae8e0 Void
+0x028 ExclusiveWaiters : 0xffffae09`a9aabea0 Void
+0x030 OwnerEntry : _OWNER_ENTRY
+0x040 ActiveEntries : 1
+0x044 ContentionCount : 0xbfef
+0x048 NumberOfSharedWaiters : 1
+0x04c NumberOfExclusiveWaiters : 6
+0x050 Reserved2 : (null)
+0x058 Address : (null)
+0x058 CreatorBackTraceIndex : 0
+0x060 SpinLock : 0
3: kd> dx -id 0,0,ffffcf8cdcc92040 -r1 (*((ntkrnlmp!_OWNER_ENTRY *)0xffffcf8ce08d08c0))
(*((ntkrnlmp!_OWNER_ENTRY *)0xffffcf8ce08d08c0)) [Type: _OWNER_ENTRY]
[+0x000] OwnerThread : 0xffffcf8cf18e3080 [Type: unsigned __int64]
[+0x008 ( 0: 0)] IoPriorityBoosted : 0x0 [Type: unsigned long]
[+0x008 ( 1: 1)] OwnerReferenced : 0x0 [Type: unsigned long]
[+0x008 ( 2: 2)] IoQoSPriorityBoosted : 0x1 [Type: unsigned long]
[+0x008 (31: 3)] OwnerCount : 0x1 [Type: unsigned long]
[+0x008] TableSize : 0xc [Type: unsigned long]
3: kd> dx -id 0,0,ffffcf8cdcc92040 -r1 ((ntkrnlmp!_OWNER_ENTRY *)0xffffcf8cee6e8210)
((ntkrnlmp!_OWNER_ENTRY *)0xffffcf8cee6e8210) : 0xffffcf8cee6e8210 [Type: _OWNER_ENTRY *]
[+0x000] OwnerThread : 0x0 [Type: unsigned __int64]
[+0x008 ( 0: 0)] IoPriorityBoosted : 0x1 [Type: unsigned long]
[+0x008 ( 1: 1)] OwnerReferenced : 0x1 [Type: unsigned long]
[+0x008 ( 2: 2)] IoQoSPriorityBoosted : 0x1 [Type: unsigned long]
[+0x008 (31: 3)] OwnerCount : 0x0 [Type: unsigned long]
[+0x008] TableSize : 0x7 [Type: unsigned long]
Thanks for reporting this. I've tracked this down to an OS bug: there's a deadlock in wanarp. This issue appears to affect every version of the OS going back to Windows Vista.
I've filed internal issue task.ms/42393356 to track this: if you have a Microsoft support contract, your rep can get you status updates on that issue.
Meanwhile, you can partially work around this issue by either:
Indicating 1 packet at a time (NumberOfNetBufferLists==1); or
Indicating on a single CPU at a time
The bug in wanarp is exposed when 2 or more CPUs collectively process 3 or more NBLs at the same time. So either workaround would avoid the trigger conditions.
Depending on how much bandwidth you're pushing through this network interface, those options could be rather bad for CPU/battery/throughput. So please try to avoid pessimizing batching unless it's really necessary. (For example, you could make this an option that's off-by-default, unless the customer specifically uses wanarp.)
Note that you cannot fully prevent the issue yourself. Other drivers in the stack, including NDIS itself, have the right to group packets together, which would have the side effect re-batching the packets that you carefully un-batched. However, I believe that you can make a statistically significant dent in the crashes if you just indicate 1 NBL at a time, or indicate multiple NBLs on 1 CPU at a time.
Sorry this is happening to you again! wanarp is... a very old codebase.

Opening a positron emission tomography (PET) DICOM image in MatLab and interpreting the pixel values correctly?

I'm new to processing DICOM images away from their native manufacturer software. I am trying to dicomread a PET image from a set of reconstructed transaxial slices into MatLab. My aim is to do some simple segmentation and finally determine the maximum and minimum pixel value in the segment. However I am having trouble with converting the stored values to their values seen on the native system.
The image is loading into MatLab as an int16 class. The maximum pixel value is always 32767, regardless of which slice I load from the series. I know from viewing the images on their native system that the maximum pixel value in each slice is different.
I've checked the rescale value and rescale intercept values and the rescale relationship appears to be linear. Is there another correction I should be making? I assume all other corrections (e.g. decay, scatter and randoms) are made during the reconstruction process.
Any help would be appreciated (hopefully I'm missing something simple!).I've posted the DICOM info retrieved from the header below (Don't worry, the images are of a phantom so there is no patient identifying data).
Regards,
Ross
Filename: [1x76 char]
FileModDate: '26-Jul-2013 10:50:42'
FileSize: 38356
Format: 'DICOM'
FormatVersion: 3
Width: 128
Height: 128
BitDepth: 16
ColorType: 'grayscale'
FileMetaInformationGroupLength: 182
FileMetaInformationVersion: [2x1 uint8]
MediaStorageSOPClassUID: '1.2.840.10008.5.1.4.1.1.128'
MediaStorageSOPInstanceUID: [1x49 char]
TransferSyntaxUID: '1.2.840.10008.1.2.1'
ImplementationClassUID: '1.2.840.113619.6.55'
SourceApplicationEntityTitle: 'dst01'
IdentifyingGroupLength: 484
SpecificCharacterSet: 'ISO_IR 100'
ImageType: 'ORIGINAL\PRIMARY'
InstanceCreationDate: '20130522'
InstanceCreationTime: '171655'
InstanceCreatorUID: '1.2.840.113619.1.131'
SOPClassUID: '1.2.840.10008.5.1.4.1.1.128'
SOPInstanceUID: [1x49 char]
StudyDate: '20130514'
SeriesDate: '20130514'
AcquisitionDate: '20130514'
ContentDate: '20130522'
StudyTime: '142911'
SeriesTime: '143208.00'
AcquisitionTime: '143208.00'
ContentTime: '171655'
AccessionNumber: ''
Modality: 'PT'
Manufacturer: 'GE MEDICAL SYSTEMS'
InstitutionName: 'NHS TRUST'
ReferringPhysicianName: [1x1 struct]
StationName: 'dst01'
StudyDescription: ''
SeriesDescription: 'WB_3D_VuePoint'
PhysicianReadingStudy: [1x1 struct]
OperatorName: [1x1 struct]
ManufacturerModelName: 'Discovery STE'
Private_0009_GroupLength: 2714
Private_0009_10xx_Creator: 'GEMS_PETD_01'
Private_0009_11xx_Creator: 'GEMS_GENIE_1'
Private_0009_1002: 'SOLID_TEST'
Private_0009_1005: '20130514143030.00'
Private_0009_1006: 0
Private_0009_100a: [1x45 char]
Private_0009_100d: '20130514143208.00'
Private_0009_100e: '20130514143055.00'
Private_0009_1013: [1x59 char]
Private_0009_1014: 'Sternal Notch'
Private_0009_1015: 'SN'
Private_0009_1016: 0
Private_0009_1017: 0
Private_0009_1018: 0
Private_0009_1019: 0
Private_0009_101a: 1
Private_0009_101b: 0
Private_0009_101c: 1
Private_0009_101d: 0
Private_0009_101e: 1
Private_0009_101f: 1
Private_0009_1020: 0
Private_0009_1021: 1
Private_0009_1022: 0
Private_0009_1023: 0
Private_0009_1024: 2
Private_0009_1025: 2
Private_0009_1026: 23
Private_0009_1027: 1
Private_0009_1028: 1
Private_0009_1029: 0
Private_0009_102a: 0
Private_0009_102b: 70
Private_0009_102c: 153
Private_0009_102d: 0
Private_0009_102e: 0
Private_0009_1034: 0
Private_0009_1035: 0
Private_0009_1036: 'FDG -- fluorodeoxyglucose'
Private_0009_1037: ''
Private_0009_1038: 0
Private_0009_1039: ''
Private_0009_103a: 0
Private_0009_103b: ''
Private_0009_103c: 0
Private_0009_103d: ''
Private_0009_103e: '18F'
Private_0009_103f: 6588
Private_0009_1040: 0.9700
Private_0009_104d: 0
Private_0009_104e: 23
Private_0009_104f: 23
Private_0009_1050: 7
Private_0009_1051: 7
Private_0009_1052: 32
Private_0009_1053: 800
Private_0009_1054: 650
Private_0009_1055: 425
Private_0009_1056: [1x49 char]
Private_0009_1057: [1x48 char]
Private_0009_1059: [1x49 char]
Private_0009_105a: 0
Private_0009_105c: [1x49 char]
Private_0009_105d: [1x45 char]
Private_0009_105e: [1x51 char]
Private_0009_105f: 'SOLID_TEST'
Private_0009_1062: [1x44 char]
Private_0009_1063: 0
Private_0009_1064: 0
Private_0009_1066: 119.5000
Private_0009_1067: -79.8540
Private_0009_1068: '20130514143123.00'
Private_0009_1069: 553
Private_0009_106a: -79.9000
Private_0009_106b: 0
Private_0009_106c: '20130514143208.00'
Private_0009_106d: 180
Private_0009_1070: 0
Private_0009_1071: 90674329
Private_0009_1072: 0
Private_0009_1073: 1
Private_0009_1074: 255
Private_0009_107c: 0
Private_0009_107d: 2
Private_0009_107e: 0
Private_0009_107f: 0
Private_0009_1080: 0
Private_0009_1081: 0
Private_0009_108b: 5
Private_0009_108c: 2
Private_0009_108d: 0.0960
Private_0009_108e: 0
Private_0009_108f: 0
Private_0009_1090: 0
Private_0009_1091: 0
Private_0009_1092: 0
Private_0009_1093: 0
Private_0009_1094: 0
Private_0009_1095: 0
Private_0009_1096: [1x49 char]
Private_0009_1097: [1x51 char]
Private_0009_1098: [1x49 char]
Private_0009_1099: ''
Private_0009_109a: 0
Private_0009_109b: 0
Private_0009_109c: ''
Private_0009_109d: 0
Private_0009_109e: 0
Private_0009_109f: 0
Private_0009_10a0: 0
Private_0009_10a1: 0
Private_0009_10a2: 0
Private_0009_10a3: 0
Private_0009_10a6: 26
Private_0009_10a7: 0
Private_0009_10ab: 0
Private_0009_10ac: 0
Private_0009_10ad: ''
Private_0009_10ae: ''
Private_0009_10b2: 2
Private_0009_10b3: 20
Private_0009_10b4: 70
Private_0009_10b5: 0
Private_0009_10b6: 0
Private_0009_10b7: 0
Private_0009_10b8: 0
Private_0009_10b9: 0
Private_0009_10ba: 1
Private_0009_10bb: 6
Private_0009_10bc: 0
Private_0009_10bd: 0
Private_0009_10be: 0
Private_0009_10bf: 0
Private_0009_10c0: 0
Private_0009_10c1: 0
Private_0009_10c2: 0
Private_0009_10c3: 0
Private_0009_10c4: 6
Private_0009_10c5: 0
Private_0009_10c6: 0
Private_0009_10c7: 0
Private_0009_10cb: 0.8601
Private_0009_10cc: 0.1256
Private_0009_10cd: 0.8240
Private_0009_10ce: -0.0254
Private_0009_10cf: 0.5000
Private_0009_10d0: -0.0483
Private_0009_10d5: 0
Private_0009_10d6: 70.5000
Private_0009_10d7: -79.9000
Private_0009_10d8: 1
Private_0009_10db: 3
Private_0009_10dc: 2
Private_0009_10df: 47
Private_0009_10e2: 10
Private_0009_10e4: '3D_AC'
Private_0009_10e5: 0
Private_0009_10e6: 0
Private_0009_10e7: 0
Private_0009_10e9: 0
Private_0009_10ea: 0
Private_0009_10eb: 0
Private_0009_10ec: 0
Private_0009_111e: [1x49 char]
Private_0009_1146: [1x49 char]
PatientGroupLength: 96
PatientName: [1x1 struct]
PatientID: 'SOLID_TEST'
PatientBirthDate: ''
PatientSex: ''
PatientAge: ''
PatientSize: 0
PatientWeight: 0
EthnicGroup: ''
AdditionalPatientHistory: ''
Private_0017_GroupLength: 46
Private_0017_10xx_Creator: 'GEMS_PETD_01'
Private_0017_1004: '20130207140047.00'
AcquisitionGroupLength: 230
SliceThickness: 3.2700
AcquisitionTerminationCondition: 'TIME'
AcquisitionStartCondition: 'MANU'
AcquisitionStartConditionData: 0
AcquisitionTerminationConditionData: 0
SoftwareVersion: '41.04'
ProtocolName: 'WB 3D'
TriggerTime: 0
FrameTime: 0
IntervalsAcquired: 0
IntervalsRejected: 0
ReconstructionDiameter: 700
GantryDetectorTilt: 0
FieldOfViewShape: 'CYLINDRICAL RING'
FieldOfViewDimensions: [2x1 double]
CollimatorType: 'NONE'
ActualFrameDuration: 180000
PatientPosition: 'HFS'
Private_0019_GroupLength: 42
Private_0019_10xx_Creator: 'GEMS_PETD_01'
Private_0019_1004: '20130207140602'
RelationshipGroupLength: 322
StudyInstanceUID: [1x51 char]
SeriesInstanceUID: [1x49 char]
StudyID: '6893'
SeriesNumber: 401
InstanceNumber: 22
ImagePositionPatient: [3x1 double]
ImageOrientationPatient: [6x1 double]
FrameOfReferenceUID: [1x59 char]
PositionReferenceIndicator: 'SN'
SliceLocation: 1.8500
ImagePresentationGroupLength: 218
SamplesPerPixel: 1
PhotometricInterpretation: 'MONOCHROME2'
Rows: 128
Columns: 128
PixelSpacing: [2x1 double]
CorrectedImage: [1x40 char]
BitsAllocated: 16
BitsStored: 16
HighBit: 15
PixelRepresentation: 1
SmallestImagePixelValue: 0
LargestImagePixelValue: 32767
RescaleIntercept: 0
RescaleSlope: 0.3555
LossyImageCompression: '00'
Unknown_0040_0000: 158
AcquisitionContextSequence: [1x1 struct]
NuclearAcquisitionGroupLength: 808
EnergyWindowRangeSequence: [1x1 struct]
RadiopharmaceuticalInformationSequence: [1x1 struct]
NumberOfSlices: 47
TypeOfDetectorMotion: 'NONE'
PatientOrientationCodeSequence: [1x1 struct]
PatientOrientationModifierCodeSequence: [1x1 struct]
PatientGantryRelationshipCodeSequence: [1x1 struct]
SeriesType: 'STATIC\IMAGE'
Units: 'BQML'
CountsSource: 'EMISSION'
RandomsCorrectionMethod: 'SING'
AttenuationCorrectionMethod: 'measured,, 0.096000 cm-1,'
DecayCorrection: 'START'
ReconstructionMethod: '3D IR'
DetectorLinesOfResponseUsed: '0'
ScatterCorrectionMethod: 'Model Based'
AxialMash: [2x1 double]
TransverseMash: 2
CoincidenceWindowWidth: 0
FrameReferenceTime: 0
PrimaryPromptsCountsAccumulated: 0
SecondaryCountsAccumulated: 0
SliceSensitivityFactor: 1
DecayFactor: 1.0095
DoseCalibrationFactor: 1139
ScatterFractionFactor: 0.3174
DeadTimeFactor: 1.1243
ImageIndex: 26
PixelDataGroupLength: 32780
I work in mammo and have no experience of PET so take what I say here with a pinch of salt.
The maximum pixel value is 32767 which is 2 to the power of 15 minus 1. Is the rescale slope not of importance?
RescaleSlope: 0.3555
Presumably this can vary for each slice and the pixel values should be multiplied by this value (intercept should be added too but this is zero).
Out of the major scanner manufacturers (Siemens, GE, Philips) I have only encountered a slice-by-slice RescaleSlope value when working with GE PET cameras. However, it is always a good idea to check RescaleSlope and RescaleIntercept. The QIBA working group on FDG-PET has a collection of recommendations and also pseudocode for SUV calculations straight from the DICOM data.

Pig Join is returning no results

I have been stuck on this problem for over twelve hours now. I have a Pig script that is running on Amazon Web Services. Currently, I am just running my script in interactive mode. I am trying to get averages on a large data set of climate readings from weather stations; however, this data doesn't have country or state information so it has to be joined with another table that does.
State Table:
719990 99999 LILLOOET CN CA BC WKF +50683 -121933 +02780
719994 99999 SEDCO 710 CN CA CWQJ +46500 -048500 +00000
720000 99999 BOGUS AMERICAN US US -99999 -999999 -99999
720001 99999 PEASON RIDGE/RANGE US US LA K02R +31400 -093283 +01410
720002 99999 HALLOCK(AWS) US US MN K03Y +48783 -096950 +02500
720003 99999 DEER PARK(AWS) US US WA K07S +47967 -117433 +06720
720004 99999 MASON US US MI K09G +42567 -084417 +02800
720005 99999 GASTONIA US US NC K0A6 +35200 -081150 +02440
Climate Table: (I realize this doesn't contain anything to satisfy the join condition, but the full data set does.)
STN--- WBAN YEARMODA TEMP DEWP SLP STP VISIB WDSP MXSPD GUST MAX MIN PRCP SNDP FRSHTT
010010 99999 20090101 23.3 24 15.6 24 1033.2 24 1032.0 24 13.5 6 9.6 24 17.5 999.9 27.9* 16.7 0.00G 999.9 001000
010010 99999 20090102 27.3 24 20.5 24 1026.1 24 1024.9 24 13.7 5 14.6 24 23.3 999.9 28.9 25.3* 0.00G 999.9 001000
010010 99999 20090103 25.2 24 18.4 24 1028.3 24 1027.1 24 15.5 6 4.2 24 9.7 999.9 26.2* 23.9* 0.00G 999.9 001000
010010 99999 20090104 27.7 24 23.2 24 1019.3 24 1018.1 24 6.7 6 8.6 24 13.6 999.9 29.8 24.8 0.00G 999.9 011000
010010 99999 20090105 19.3 24 13.0 24 1015.5 24 1014.3 24 5.6 6 17.5 24 25.3 999.9 26.2* 10.2* 0.05G 999.9 001000
010010 99999 20090106 12.9 24 2.9 24 1019.6 24 1018.3 24 8.2 6 15.5 24 25.3 999.9 19.0* 8.8 0.02G 999.9 001000
010010 99999 20090107 26.2 23 20.7 23 998.6 23 997.4 23 6.6 6 12.1 22 21.4 999.9 31.5 19.2* 0.00G 999.9 011000
010010 99999 20090108 21.5 24 15.2 24 995.3 24 994.1 24 12.4 5 12.8 24 25.3 999.9 24.6* 19.2* 0.05G 999.9 011000
010010 99999 20090109 27.5 23 24.5 23 982.5 23 981.3 23 7.9 5 20.2 22 33.0 999.9 34.2 20.1* 0.00G 999.9 011000
010010 99999 20090110 22.5 23 16.7 23 977.2 23 976.1 23 11.9 6 15.5 23 35.0 999.9 28.9* 17.2 0.09G 999.9 000000
I load in the climate data using TextLoader, apply a regular expression to obtain the fields, and filter out the nulls from the result set. I then do the same with the state data, but I filter it for the country being the US.
The bags have the following schema:
CLIMATE_REMOVE_EMPTY: {station: int,wban: int,year: int,month: int,day: int,temp: double}
STATES_FILTER_US: {station: int,wban: int,name: chararray,wmo: chararray,fips: chararray,state: chararray}
I need to perform a join operation on (station,wban) so I can get a resulting bag with the station, wban, year, month, and temps. When I perform a dump on the resulting bag, it says that it was successful; however, the dump returns 0 results. This is the output.
HadoopVersion PigVersion UserId StartedAt FinishedAt Features
1.0.3 0.9.2-amzn hadoop 2013-05-03 00:10:51 2013-05-03 00:12:42 HASH_JOIN,FILTER
Success!
Job Stats (time in seconds):
JobId Maps Reduces MaxMapTime MinMapTIme AvgMapTime MaxReduceTime MinReduceTime AvgReduceTime Alias Feature Outputs
job_201305030005_0001 2 1 36 15 25 33 33 33 CLIMATE,CLIMATE_REMOVE_NULL,RAW_CLIMATE,RAW_STATES,STATES,STATES_FILTER_US,STATE_CLIMATE_JO IN HASH_JOIN hdfs://10.204.30.125:9000/tmp/temp-204730737/tmp1776606203,
Input(s):
Successfully read 30587 records from: "hiddenbucket"
Successfully read 21027 records from: "hiddenbucket"
Output(s):
Successfully stored 0 records in: "hdfs://10.204.30.125:9000/tmp/temp-204730737/tmp1776606203"
Counters:
Total records written : 0
Total bytes written : 0
Spillable Memory Manager spill count : 0
Total bags proactively spilled: 0
Total records proactively spilled: 0
I have no idea why my this contains 0 results. My data extraction seems correct. and the job is successful. It leads me to believe that the join condition is never satisfied. I know the input files have some data that should satisfy the join condition, but it returns absolutely nothing.
The only thing that looks suspicious is a warning that states:
Encountered Warning ACCESSING_NON_EXISTENT_FIELD 26001 time(s).
I'm not exactly sure where to go from here. Since the job isn't failing, I can't see any errors or anything in debug.
I'm not sure if these mean anything, but here are other things that stand out:
When I try to illustrate STATE_CLIMATE_JOIN, I get a nullPointerException - ERROR 2997: Encountered IOException. Exception : null
When I try to illustrate STATES, I get java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
Here is my full code:
--Piggy Bank Functions
register file:/home/hadoop/lib/pig/piggybank.jar
DEFINE EXTRACT org.apache.pig.piggybank.evaluation.string.EXTRACT();
--Load Climate Data
RAW_CLIMATE = LOAD 'hiddenbucket' USING TextLoader as (line:chararray);
RAW_STATES= LOAD 'hiddenbucket' USING TextLoader as (line:chararray);
CLIMATE=
FOREACH
RAW_CLIMATE
GENERATE
FLATTEN ((tuple(int,int,int,int,int,double))
EXTRACT(line,'^(\\d{6})\\s+(\\d{5})\\s+(\\d{4})(\\d{2})(\\d{2})\\s+(\\d{1,3}\\.\\d{1})')
)
AS (
station: int,
wban: int,
year: int,
month: int,
day: int,
temp: double
)
;
STATES=
FOREACH
RAW_STATES
GENERATE
FLATTEN ((tuple(int,int,chararray,chararray,chararray,chararray))
EXTRACT(line,'^(\\d{6})\\s+(\\d{5})\\s+(\\S+)\\s+(\\w{2})\\s+(\\w{2})\\s+(\\w{2})')
)
AS (
station: int,
wban: int,
name: chararray,
wmo: chararray,
fips: chararray,
state: chararray
)
;
CLIMATE_REMOVE_NULL = FILTER CLIMATE BY station IS NOT NULL;
STATES_FILTER_US = FILTER STATES BY (fips == 'US');
STATE_CLIMATE_JOIN = JOIN CLIMATE_REMOVE_NULL BY (station), STATES_FILTER_US BY (station);
Thanks in advance. I am at a loss here.
--EDIT--
I finally got it to work! My regular expression for parsing the STATE_DATA was invalid.

Windows Service crashes

I have a windows service running on Windows Server 2003. The service crashes ocassionlly. I tried analysis error through DebugDiag and got following information. Can anyone help me to understand the problem. The service uses GSM libaray for SMS service.
Error:
In EnfieldSMSService__PID__1764__Date__01_21_2011__Time_09_34_31AM__554__Second_Chance_Exception_C0000005.
dmp the assembly instruction at 0x00bb29d1 which does not correspond to any
known native module in the process has caused an access violation exception
(0xC0000005) when trying to read from memory location 0x00000008 on thread 10
Report for
>EnfieldSMSService__PID__1764__Date__01_21_2011__Time_09_34_31AM__554__Second_Chance_Exception_C0000005.
dmp
Type of Analysis Performed Crash Analysis
Machine Name REALTRACSERVER
Operating System Windows Server 2003 Service Pack 2
Number Of Processors 4
Process ID 1764
Process Image C:\Program Files\Default Company Name\EnfieldSMSSetUp\
EnfieldSMSService.exe
System Up-Time 7 day(s) 18:30:55
Process Up-Time 00:05:24
Thread 10 - System ID 3632
Entry point mscorwks!CreateApplicationContext+bbef
Create time 1/21/2011 9:34:31 AM
Time spent in user mode 0 Days 0:0:0.0
Time spent in kernel mode 0 Days 0:0:0.0
Function Arg 1 Arg 2 Arg 3 Source
0x00bb29d1 01041e54 00b8f8c4 792d6cf6
0x00bb11c7 01041ee0 00b8f8d8 792e019f
mscorlib_ni+216cf6 00b8f91c 01041ee0 01041eac
mscorlib_ni+22019f 01041eac 00000000 001df020
mscorlib_ni+216c74 00000217 7c82b02a 00b8f980
mscorwks+1b4c 00b8f9d0 00000000 00b8f9a0
mscorwks!DllUnregisterServerInternal+6195 00b8f9d0 00000000
00b8f9a0
mscorwks!CoUninitializeEE+2e95 7924290c 00b8fc14 00b8fb4c
mscorwks!CoUninitializeEE+2ec8 7924290c 00b8fc14 00b8fb4c
mscorwks!CoUninitializeEE+2ee6 00b8fb4c 95f5cb6e 001df020
mscorwks!CorExitProcess+1e4d 00b8fe50 00000000 00000000
mscorwks!CoUninitializeEE+4df3 00b8fdc4 00b8fd70 79f7759b
mscorwks!CoUninitializeEE+4d8f 00b8fdc4 95f5ca02 00000000
mscorwks!CoUninitializeEE+4cb5 00b8fdc4 00000001 00000000
mscorwks!CoUninitializeEE+4e41 00000001 79f3d6e9 00b8fe50
mscorwks!CorExitProcess+1c1e 00000001 79f3d6e9 00b8fe50
mscorwks!CorExitProcess+1cf8 001e2f68 00000001 00000001
mscorwks!CreateApplicationContext+bc35 0019cf88 00000000 00000000
kernel32!GetModuleHandleA+df 79f91fcf 0019cf88 00000000
Detailed stack corruption analysis for thread 10
Call stack with StackWalk
Index Return Address
1 0x00bb29d1
2 0x00bb11c7
3 mscorlib_ni+216cf6
4 mscorlib_ni+22019f
5 mscorlib_ni+216c74
6 mscorwks+1b4c
7 mscorwks!DllUnregisterServerInternal+6195
8 mscorwks!CoUninitializeEE+2e95
9 mscorwks!CoUninitializeEE+2ec8
10 mscorwks!CoUninitializeEE+2ee6
11 mscorwks!CorExitProcess+1e4d
12 mscorwks!CoUninitializeEE+4df3
13 mscorwks!CoUninitializeEE+4d8f
14 mscorwks!CoUninitializeEE+4cb5
15 mscorwks!CoUninitializeEE+4e41
16 mscorwks!CorExitProcess+1c1e
17 mscorwks!CorExitProcess+1cf8
18 mscorwks!CreateApplicationContext+bc35
19 kernel32!GetModuleHandleA+df
Call stack - Heuristic
Index Stack Address Child EBP Return Address Destination
1 0x00000000 0x00b8f8ac 0x00bb29d1 0x00000000
2 0x00b8f8b0 0x00b8f8b8 0x00bb11c7 0x00bb2940
3 0x00b8f8bc 0x00b8f8c4 mscorlib_ni+216cf6 0x00000000
4 0x00b8f8c8 0x00b8f8d8 mscorlib_ni+22019f 0x00000000
5 0x00b8f8dc 0x00b8f8f0 mscorlib_ni+216c74 mscorlib_ni+220130
6 0x00b8f8f4 0x00b8f900 mscorwks+1b4c 0x00000000
7 0x00b8f904 0x00b8f980 mscorwks!DllUnregisterServerInternal+6195
mscorwks+1b19
8 0x00b8f984 0x00b8fab8 mscorwks!CoUninitializeEE+2e95 mscorwks!
DllUnregisterServerInternal+60f6
9 0x00b8fabc 0x00b8fad4 mscorwks!CoUninitializeEE+2ec8 mscorwks!
CoUninitializeEE+2d3b
10 0x00b8fad8 0x00b8faec mscorwks!CoUninitializeEE+2ee6 mscorwks!
CoUninitializeEE+2ea9
11 0x00b8faf0 0x00b8fcd4 mscorwks!CorExitProcess+1e4d mscorwks!
CoUninitializeEE+2ecc
12 0x00b8fcd8 0x00b8fce8 mscorwks!CoUninitializeEE+4df3 0x00000000
13 0x00b8fcec 0x00b8fd7c mscorwks!CoUninitializeEE+4d8f mscorwks!
CoUninitializeEE+4dc8
14 0x00b8fd80 0x00b8fdb8 mscorwks!CoUninitializeEE+4cb5 mscorwks!
CoUninitializeEE+4ce0
15 0x00b8fdbc 0x00b8fde0 mscorwks!CoUninitializeEE+4e41 mscorwks!
CoUninitializeEE+4c90
16 0x00b8fde4 0x00b8fdf8 mscorwks!CorExitProcess+1c1e mscorwks!
CoUninitializeEE+4e1c
17 0x00b8fdfc 0x00b8fe94 mscorwks!CorExitProcess+1cf8 mscorwks!
CorExitProcess+1c0b
18 0x00b8fe98 0x00b8ffb8 mscorwks!CreateApplicationContext+bc35 0x00000000
19 0x00b8ffbc 0x00b8ffec kernel32!GetModuleHandleA+df 0x00000000
792d6cf4 ffd0 call eax
792e019d ffd0 call eax
792d6c6f e8bc940000 call mscorlib_ni+0x220130 (792e0130)
79e71b49 ff5518 call dword ptr [ebp+18h]
79e821ac e868f9feff call mscorwks+0x1b19 (79e71b19)
79e964fc e811bcfeff call mscorwks!DllUnregisterServerInternal+0x60f6
(79e82112)
79e9652f e873feffff call mscorwks!CoUninitializeEE+0x2d3b (79e963a7)
79e9654d e8c3ffffff call mscorwks!CoUninitializeEE+0x2ea9 (79e96515)
79f3d7fe e8358df5ff call mscorwks!CoUninitializeEE+0x2ecc (79e96538)
79e9845c ff560c call dword ptr [esi+0Ch]
79e983f6 e839000000 call mscorwks!CoUninitializeEE+0x4dc8 (79e98434)
79e9831c e82b000000 call mscorwks!CoUninitializeEE+0x4ce0 (79e9834c)
79e984a8 e84ffeffff call mscorwks!CoUninitializeEE+0x4c90 (79e982fc)
79f3d5cf e8b4aef5ff call mscorwks!CoUninitializeEE+0x4e1c (79e98488)
79f3d6a9 e813ffffff call mscorwks!CorExitProcess+0x1c0b (79f3d5c1)
79f92013 ffd6 call esi
77e64826 ff5508 call dword ptr [ebp+8]
In EnfieldSMSService__PID__1764__Date__01_21_2011__Time_09_34_31AM__554__Second_Chance_Exception_C0000005.
dmp the assembly instruction at 0x00bb29d1 which does not correspond to any
known native module in the process has caused an access violation exception
(0xC0000005) when trying to read from memory location 0x00000008 on thread 10

Resources