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/00009617.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.