WinDbg issues only in Windows 7

I'm pretty new to using WinDbg, but recently my application started having issues, but only on Windows 7 machines (it runs fine the first time the PC is started but crashes or just disappears silently each time after).

I got the mdmp file, but find myself somewhat lacking on how best to extract the data I need from it. I got the following analysis (might be doing it wrong)...

Can anyone hopefully help shed some light on my issue or if I'm running the analysis incorrectly:

0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/Star_exe/1_0_0_0/4dbad268/KERNELBASE_dll/6_1_7600_16385/4a5bdaae/e0434352/00009617.htm?Retriage=1

FAULTING_IP: 
KERNELBASE!RaiseException+58
752d9617 c9              leave

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 752d9617 (KERNELBASE!RaiseException+0x00000058)
   ExceptionCode: e0434352 (CLR exception)
  ExceptionFlags: 00000001
NumberParameters: 5
   Parameter[0]: 80070002
   Parameter[1]: 00000000
   Parameter[2]: 00000000
   Parameter[3]: 00000000
   Parameter[4]: 57af0000

PROCESS_NAME:  Star.exe

ERROR_CODE: (NTSTATUS) 0xe0434352 - <Unable to get error code text>

EXCEPTION_CODE: (NTSTATUS) 0xe0434352 - <Unable to get error code text>

EXCEPTION_PARAMETER1:  80070002

EXCEPTION_PARAMETER2:  00000000

EXCEPTION_PARAMETER3:  00000000

EXCEPTION_PARAMETER4: 0

MOD_LIST: <ANALYSIS/>

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

MANAGED_STACK: !dumpstack -EE
No export dumpstack found

MANAGED_BITNESS_MISMATCH: 
Managed code needs matching platform of sos.dll for proper analysis. Use 'x86' debugger.

ADDITIONAL_DEBUG_TEXT:  Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]

LAST_CONTROL_TRANSFER:  from 57c03970 to 752d9617

FAULTING_THREAD:  ffffffff

DEFAULT_BUCKET_ID:  STACKIMMUNE

PRIMARY_PROBLEM_CLASS:  STACKIMMUNE

BUGCHECK_STR:  APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION_WRONG_SYMBOLS

STACK_TEXT:  
00000000 00000000 star.exe+0x0


SYMBOL_NAME:  star.exe

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: star

IMAGE_NAME:  Star.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4dbad268

STACK_COMMAND:  ** Pseudo Context ** ; kb

FAILURE_BUCKET_ID:  STACKIMMUNE_e0434352_Star.exe!Unknown

BUCKET_ID:  APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION_WRONG_SYMBOLS_star.exe

FOLLOWUP_IP: *** WARNING: Unable to verify timestamp for Star.exe

Star!.ctor+0 [C:\Users\Aj\Documents\Visual Studio 2010\Projects\Star\Star\ViewModels\ViewModelBase.cs @ 22]
00360000 ??              ???

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/Star_exe/1_0_0_0/4dbad268/KERNELBASE_dll/6_1_7600_16385/4a5bdaae/e0434352/000096开发者_运维百科17.htm?Retriage=1

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

You may want to use this article as a starting point: SOS: It's Not Just an ABBA Song Anymore

It looks like your application is a .NET application, make sure you've got the right .NET Framework installed. When you load the sos.dll file into windbg, you may have to provide a full path. Also, you can set up access to the public microsoft symbol servers to help with some of your stack tracing. This article may help: Debugging Tools and Symbols: Getting Started. Make sure you've got the latest version of the debugging tools.

!analyze will give you some information about the fault, but not too much else. You should look at the first article to see what else is going on.

Posting some information about your application will also help people see if you are having a similar issue.

It looks like the fault is happening in your ViewModelBase.cs file. You may want to add some logging (using log4net or similar tool) to catch the exception and print out the stack trace. You can also hook into AppDomain.CurrentDomain.UnhandledException event (or the Application.DispatcherUnhandledException event for WPF applications) to catch anything that's getting thrown and printing out something to a log file. In this case, you won't need to resort to WinDbg to figure out what's going on.

Well after several weeks of searching (maybe more), it turns out that when using Trend Micro Corporate, XP to Server 2003 is fine, Vista and Windows 7 to 2003 is fine, and even XP/Vista to server 2008 is fine, but (and I have no idea why), when using Windows 7 and trying to run a network application using a UNC path in the shortcut, it blocks certain pieces of the network traffic for that application, and it does so sporadically and what seems to be without any sound logic. I can't say why as we never quite figured out what exactly the catalyst was for setting off Trend, but I do know that when we disabled Trend, all was back to normal (something I wished we tried sooner). We found that by mapping a drive to our share and changing our shortcuts on our users workstations to use the mapped drive rather than a UNC path, the issue was averted.

Hopefully no one else runs into this problem, but if they do, this will perhaps shed some light on the issue.

Thank you! Aj