On Mon, Aug 29, 2016 at 12:08 AM, Bob Hood wrote:
> Breaking on that function produced the following stack trace:
I'm glad you found the culprit, but actually the "ModLoad" lines are
just printed by the debugger as DLLs are loaded. The stac[k] trace [1]
attempts to walk the
On 8/27/2016 12:02 PM, eryk sun wrote:
On Sat, Aug 27, 2016 at 2:19 PM, Bob Hood wrote:
From what I can tell, it's not actually a crash. It appears to be an exit()
with a result of 1, so it's not going to be easy to track down.
Break on ntdll!RtlExitUserProcess to print
On Sat, Aug 27, 2016 at 2:19 PM, Bob Hood wrote:
>
> From what I can tell, it's not actually a crash. It appears to be an exit()
> with a result of 1, so it's not going to be easy to track down.
Break on ntdll!RtlExitUserProcess to print a stack trace.
Have you tried using PTVS and attaching to process with the Python debug
engine enabled? Then you can set a breakpoint in managed code and look for
calls to sys.exit
On Sat, Aug 27, 2016 at 7:23 AM Bob Hood wrote:
> On 8/25/2016 9:36 PM, eryk sun wrote:
> > On Fri, Aug 26,
On 8/25/2016 9:36 PM, eryk sun wrote:
On Fri, Aug 26, 2016 at 12:42 AM, Bob Hood wrote:
Any suggestions as to how I could determine the cause of the crash without
having to uninstall ALL of my software?
Configure a postmortem debugger [1] (e.g. windbg -I). Use gflags to
On Fri, Aug 26, 2016 at 12:42 AM, Bob Hood wrote:
> Any suggestions as to how I could determine the cause of the crash without
> having to uninstall ALL of my software?
Configure a postmortem debugger [1] (e.g. windbg -I). Use gflags to
temporarily enable full page-heap
I have a situation where I'm using win32com.server to create an in-process
Explorer shell extension for Windows (7 64-bit). The extension itself is just
a sample I pulled from stackoverflow[1].
When I install it, and restart Explorer, opening the context menu on a file
causes Explorer to