killing process

[seth melnick]

I have some apps that occassionally hang - one example is premier pro CS4 - when it hangs I cannot kill it anyway I try - I have downloading pskill, process assassin, daphne and several other apps but nothing can kill the process. I end up having to reboot and since the process wont die, the computer gets stuck at the logging off screen requiring a reboot.

any ideas how to remedy this?

 

[zigzag3143]

I have some apps that occassionally hang - one example is premier pro CS4 - when it hangs I cannot kill it anyway I try - I have downloading pskill, process assassin, daphne and several other apps but nothing can kill the process. I end up having to reboot and since the process wont die, the computer gets stuck at the logging off screen requiring a reboot.

any ideas how to remedy this?

Obviously if apps hang there is something causing them to. You should try to find out what that is.

If you are insterested Let us know

Ken

 

[seth melnick]

the apps work fine and then hang occassionally - that might be an issue in the app or compatibilty but i should be able to kill it

 

[seth melnick]

ok i did a dump from premier after it hung and analyzed it - the results are below but I am having trouble understanding it - it seems that wow64 is having a problem when accessing a file - that is the 32 bit emulator in 64 bit windows.

can anyone decipher this further? I would attach the dmp but it is over 130 MB wehen zipped


FAULTING_IP:
+0
00000000`00000000 ?? ???

EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0

FAULTING_THREAD: 0000000000000f28

PROCESS_NAME: Adobe Premiere Pro.exe

OVERLAPPED_MODULE: Address regions for 'opengl32' and 'glu32' overlap

ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload' to set symbol path and load symbols.

MODULE_NAME: wow64

FAULTING_MODULE: 0000000077130000 kernel32

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5be124

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

NTGLOBALFLAG: 0

APPLICATION_VERIFIER_FLAGS: 0

BUGCHECK_STR: APPLICATION_FAULT_CORRUPT_MODULELIST_OVERLAPPED_MODULE_WRONG_SYMBOLS

PRIMARY_PROBLEM_CLASS: CORRUPT_MODULELIST

DEFAULT_BUCKET_ID: CORRUPT_MODULELIST

LAST_CONTROL_TRANSFER: from 0000000073df62d7 to 00000000774b01ea

STACK_TEXT:
00000000`0008e2a8 00000000`73df62d7 : 00000000`0018ee54 00000000`0018ee88 00000000`00000000 00000000`fffdb000 : ntdll!ZwOpenFile+0xa
00000000`0008e2b0 00000000`73decf87 : 00000000`0018ee54 00000000`00000000 00000000`0008eba0 00000000`0018f334 : wow64!whNtOpenFile+0xa7
00000000`0008e340 00000000`73d7276d : 00000000`75229745 00000000`73de0023 00000000`00004021 00000000`0018f078 : wow64!Wow64SystemServiceEx+0xd7
00000000`0008ec00 00000000`73ded07e : 00000000`00000000 00000000`73d71920 00000000`0008ee90 00000000`77493ae1 : wow64cpu!TurboDispatchJumpAddressEnd+0x24
00000000`0008ecc0 00000000`73dec549 : 00000000`00000000 00000000`00000000 00000000`73de4ac8 00000000`7ffe0030 : wow64!RunCpuSimulation+0xa
00000000`0008ed10 00000000`774a84c8 : 00000000`002f3490 00000000`00000000 00000000`77593670 00000000`775657a0 : wow64!Wow64LdrpInitialize+0x429
00000000`0008f260 00000000`774a7623 : 00000000`00000000 00000000`774a9181 00000000`77460000 00000000`00000000 : ntdll!LdrpInitializeProcess+0x17e2
00000000`0008f760 00000000`7749308e : 00000000`0008f820 00000000`00000000 00000000`fffdf000 00000000`00000000 : ntdll! ?? ::FNODOBFM::`string'+0x2bea0
00000000`0008f7d0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe


STACK_COMMAND: ~0s; .ecxr ; kb

FOLLOWUP_IP:
wow64!whNtOpenFile+a7
00000000`73df62d7 448bd8 mov r11d,eax

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: wow64!whNtOpenFile+a7

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: wow64.dll

BUCKET_ID: WRONG_SYMBOLS

FAILURE_BUCKET_ID: CORRUPT_MODULELIST_80000003_wow64.dll!whNtOpenFile

 

[ecpcorran]

I'm having a similar issue, except it doesn't seem to be a specific program that always triggers this. Sometimes I will be doing something in firefox and it will just hang. Task manager is ineffective at killing the firefox.exe process.

I then tried using a different browser and later on explorer.exe hung when I right clicked my desktop to make a new text file.

There is no clear way to intentionally reproduce the error. It just seems to occur with enough time actively using the computer...

This also happened to me in the Windows 7 Release candidates but I had hoped it would be fixed once the OS officially shipped. I do not have this problem in Vista though I had previously been running Vista in 32bit so that might have something to do with it.

I'm concerned that this is related to drivers. I'm running a RAID 1 mirror between two 500GB drives and my Desktop and Download folders are located on this mirror. My MSI P35 motherboard is using the "Intel(R) ICH8R/ICH9R/ICH10R/DO/PCH SATA RAID Controller". This could make some sense as the RAID array is accessed when Firefox downloads files and when I go to make a text file on the desktop.

Are you running a raid array? Your system specs don't mention much beyond processor and video card. The major similarity I've noticed is that we are both using the 64 bit version of 7.

Even if a raid driver was the case, I'm not sure why this would be responsible for applications not responding to the task manager's attempts to end the process...

 

[H2SO4]

ok i did a dump from premier after it hung and analyzed it - the results are below but I am having trouble understanding it - it seems that wow64 is having a problem when accessing a file - that is the 32 bit emulator in 64 bit windows.

can anyone decipher this further? I would attach the dmp but it is over 130 MB wehen zipped

Kudos on your approach! Have rep

Counter-intuitive though it may be, analyzing a dump of a hung process is frequently much harder than a "crash". With a hang, the dump does not offer an obvious place where to start looking. You simply get the entire committed memory of the process in question, and then it's up to you to make heads or tails of why it may be unresponsive - not always a trivial task.

By comparison, a dump generated during a crash, either a kernel-mode bugcheck (BSOD) or a user-mode app crash, contains what's called an "exception record" which points to the place where the actual crash occurred, allowing WinDBG's automated analysis routine to easily zero-in on the most interesting parts of all that digital debris.

In this instance, the complexity is compounded by the fact that the app is a 32-bit process, and for reasons which are difficult to explain succinctly the info you're looking at in that debugger spew is almost completely irrelevant to the issue (not your fault at all of course).

If you want to generate a somewhat smaller summary dump for uploading, try punching in this command at the WinDBG prompt, once you've got the large dump open:

.dump /mhutpw adobeSmaller.dmp

Capitalisation matters in this instance, though obviously not for the new dump filename.

 

[seth melnick]

thanks for the reply - i am attaching the smaller dump here.

Not sure what other steps I can take - this appears to be related to the wow64 emulator and I end up rebooting several times a day due to hangs - if I had known that would happen i would have installed 32 bit win 7 and taken the memory hit - but thats in the past

any other tips or steps I can take to track this down - I am hoping to fix it and help the, im sure, many other with a similar issue.

 

[H2SO4]

thanks for the reply - i am attaching the smaller dump here.

Not sure what other steps I can take - this appears to be related to the wow64 emulator and I end up rebooting several times a day due to hangs - if I had known that would happen i would have installed 32 bit win 7 and taken the memory hit - but thats in the past

any other tips or steps I can take to track this down - I am hoping to fix it and help the, im sure, many other with a similar issue.

0:000:x86> kbn4
# ChildEBP RetAddr Args to Child
00 0018ee10 75af9702 0018ee88 00100001 0018ee3c ntdll_77640000!ZwOpenFile+0x12
01 0018f108 75af9c2a 02235670 00000000 0018f280 KERNELBASE!FindFirstFileExW+0x1cc
02 0018f128 0026b5f3 02235670 0018f280 0018f4f8 KERNELBASE!FindFirstFileW+0x16
WARNING: Stack unwind information not available. Following frames may be wrong.
03 0018f1a4 7766e20c 7766df72 00550000 00000000 ASLFoundation+0x2b5f3
0:000:x86> du 02235670
02235670 "\\?\Z:\projects\brill retirement"
022356b0 "\brill retirement.prproj"

The winmain thread has gone off to look for "brilliant retirement projects" on Z:, which I assume might be a network drive mapping. Since that thread is presumably responsible for "repainting" the app top-level window, any delays in accessing those documents on Z: might show up as unresponsiveness.

As a suggestion, check what that Z: path leads to and test what happens when you move those data elsewhere.

I can't see any suggestion whatsoever that wow64 is somehow involved. On the contrary, wow64 does its thang under every single 32-bit process running on a 64-bit box, and it's boringly reliable and unexciting. I think you're just seeing the "wow64" references when you open the dump at first. That doesn't necessarily mean it's got anything to do with the issue.

 

[seth melnick]

that is certainly a good lead - I have a nas device set as the z drive and occassionally it become unresponsive to the win 7 machine until i reboot - although I wouldnt think it would lock an application up

that is another issue I need to look into - not sure why that nas connection works MOST of the time but not always - and when it locks up, hmmmm - how to begin to even diagnose that?

 

[seth melnick]

i have disconnected my nas drive and will see if the hanging apps still happen - if not then netgear is getting a call about my readynas

 

[H2SO4]

i have disconnected my nas drive and will see if the hanging apps still happen - if not then netgear is getting a call about my readynas

As a suggestion, don't be tempted to bundle all "hanging apps" issues into the same bucket.

The dump I looked at makes me confident that the app unresponsiveness was linked to an inability to access files stored on the Z: drive that were for some reason important to the app at that point in time. However, that may have nothing to do with other apps being unresponsive at other times, and further troubelshooting of those other apps may be necessary.

Humans have a natural tendency towards pattern recognition, even when there are no patterns to recognise. It may not all be the same problem.

 

[ecpcorran]

Just an update, file access issues seemed to be the culprit in my case. Yesterday I opened up my computer case and noticed that the SATA connectors for my RAID drives were connected loosely at an angle. I'm not sure how the connection even worked prior to this or why Vista never had an issue, but fixing the these connections appears to have remedied my problem. I've gone nearly 24 hours without a hang which is far longer than I've previously managed. *knocks on wood*

Seth, have you encountered any more issues after disconnecting your NAS?

 

[seth melnick]

I have not had issues with the NAS disconnected - so this is interesting - I am starting to wonder if it is a win 7 issue perhaps when file access has issues - maybe the app is not notified.,

I am working with netgear to resolve the issue on their end because clearly for me, it always is related to the NAS - everytime an app freezes, explorer also freezes when I try to access the NAS

 

[H2SO4]

I have not had issues with the NAS disconnected - so this is interesting - I am starting to wonder if it is a win 7 issue perhaps when file access has issues - maybe the app is not notified.,

I am working with netgear to resolve the issue on their end because clearly for me, it always is related to the NAS - everytime an app freezes, explorer also freezes when I try to access the NAS

Your problem is caused by some type of partial access to the NAS which is presumably a problem in the NAS itself. (Most) Apps have absolutely no notion of what it may mean to be "temporarily" experiencing network problems. They don't even understand what a network is. All the app knows is that a drive called Z: apparently exists, and that you've told it to work with certain files on that drive.

Should the NAS develop problems, that shows up to the app as a partial inability to access the Z: drive. Clearly it's not a complete access breakdown, otherwise the OS would realise that something is dreadfully wrong and say "no" to apps attempting to access content on the Z: drive. Instead, the NAS shows just enough signs of life to somehow keep both Windows and the app(s) limping along under the impression that it (the NAS) will respond eventually.

Fix the NAS and the problem manifested in that hang dump will go away.

 

[seth melnick]

i have been working with netgear and they cant figure this out yet - even after the connection to the readynas hangs I can access it with a win xp machine - this leads me to beleive the issue may be in win 7

 

[H2SO4]

i have been working with netgear and they cant figure this out yet - even after the connection to the readynas hangs I can access it with a win xp machine - this leads me to beleive the issue may be in win 7

As a suggestion, once you're confident that the Adobe app is fine as long as it's not being asked to deal with info off the half-zombified Z: drive, move on to troubleshooting the network connectivity problem as a separate issue.

 

[seth melnick]

ok got more info here - here is the avid dump analysis with windbg when it freezes due to the nas issue - can anyone decipher this?

FAULTING_IP:
+0
00000000`00000000 ?? ???

EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0

FAULTING_THREAD: 00000000000015ec

DEFAULT_BUCKET_ID: STATUS_BREAKPOINT

PROCESS_NAME: AvidMediaComposer.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

NTGLOBALFLAG: 0

APPLICATION_VERIFIER_FLAGS: 0

PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT

BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT

LAST_CONTROL_TRANSFER: from 0000000074d3abfd to 000000007709028a

STACK_TEXT:
00000000`0008e2b8 00000000`74d3abfd : 00000000`0018e914 00000000`fffdb000 00000000`fffdd000 00000000`fffdb000 : ntdll!NtQueryAttributesFile+0xa
00000000`0008e2c0 00000000`74d2cf87 : 00000000`0018e9c8 00000000`0018e900 00000000`fffdb000 00000000`0018e4ec : wow64!whNtQueryAttributesFile+0x91
00000000`0008e340 00000000`74cb276d : 00000000`766cce75 00000000`74d20023 00000000`14b23558 00000000`0018f17c : wow64!Wow64SystemServiceEx+0xd7
00000000`0008ec00 00000000`74d2d07e : 00000000`00000000 00000000`74cb1920 00000000`0008ee90 00000000`77073ae1 : wow64cpu!TurboDispatchJumpAddressEnd+0x24
00000000`0008ecc0 00000000`74d2c549 : 00000000`00000000 00000000`00000000 00000000`74d24ac8 00000000`7ffe0030 : wow64!RunCpuSimulation+0xa
00000000`0008ed10 00000000`770884c8 : 00000000`00303250 00000000`00000000 00000000`77173670 00000000`771457a0 : wow64!Wow64LdrpInitialize+0x429
00000000`0008f260 00000000`77087623 : 00000000`00000000 00000000`77089181 00000000`77040000 00000000`00000000 : ntdll!LdrpInitializeProcess+0x17e2
00000000`0008f760 00000000`7707308e : 00000000`0008f820 00000000`00000000 00000000`fffdf000 00000000`00000000 : ntdll! ?? ::FNODOBFM::`string'+0x2bea0
00000000`0008f7d0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe


STACK_COMMAND: ~0s; .ecxr ; kb

FOLLOWUP_IP:
wow64!whNtQueryAttributesFile+91
00000000`74d3abfd 85db test ebx,ebx

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: wow64!whNtQueryAttributesFile+91

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: wow64

IMAGE_NAME: wow64.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5be124

FAILURE_BUCKET_ID: STATUS_BREAKPOINT_80000003_wow64.dll!whNtQueryAttributesFile

BUCKET_ID: X64_APPLICATION_FAULT_STATUS_BREAKPOINT_wow64!whNtQueryAttributesFile+91

WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOn...0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1

Followup: MachineOwner
---------

 

[H2SO4]

ok got more info here - here is the avid dump analysis with windbg when it freezes due to the nas issue - can anyone decipher this?

...

FAILURE_BUCKET_ID: STATUS_BREAKPOINT_80000003_wow64.dll!whNtQueryAttributesFile

Same deal again, almost certainly. The app has been configured to work with files on a drive whose accessibility is unreliable. Until the kernel call returns, the thread is stuck and it's not going to be repainting the UI window or doing other things which the user (you) associates with signs of life from the app.

Try to approach this problem from the angle of ...

"Why does my Windows machine sometimes have problems talking to the NAS?"

... rather than...

"Why are my apps which deal with files stored on the NAS sometimes unresponsive?"

Make sure you uninstall (as opposed to mere disabling) the anti-virus utility on that Windows box, and then test what happens without it. If the NAS access problem is on the Win7 box, statistically the most likely culprit is the AV.