Thanks for your reply. I tested this on another box and I did not get the error. I then tried different code that uses COM to manipulate Excel on my machine which I know works and has worked in the past and I ended up getting the error with that code. So I know for sure it is the local install of Excel on my machine.
Thanks for your help Mark and Tim. I greatly appreciate it. Sorry to bother you and the mailing list with a problem that was not rooted in pywin32. Mark -----Original Message----- From: Mark Hammond [mailto:skippy.hamm...@gmail.com] Sent: Tuesday, May 31, 2011 10:09 PM To: Mark Mordeca Cc: python-win32@python.org Subject: Re: [python-win32] Excel "stopped working" after reading in sheet names On 31/05/2011 6:09 PM, Tim Golden wrote: > On 30/05/2011 21:26, Mark Mordeca wrote: >> Greetings, >> >> I would appreciate any help I could get with the following problem. 30% >> of the time after running the following code to get the sheet names out >> of an excel file, I will receive a windows error saying that "Microsoft >> Office Excel has stopped working". > > A few points: > > * The underlying problem is almost certainly going to be a subtle > timing interaction around the refcounting on the pywin32 CDispatch > objects which are proxying for the underlying Windows objects. > It's a maze of twisty passages, so I'll let Mark or Roger comment > if they think there's something to be said. Unless I misunderstand, I don't think that will be the problem. The sample is simple enough that each of the Python objects will die deterministically (ie, without relying on GC etc), which means all COM references will also be managed deterministically. IOW, I think anyone running the sample will have exactly the same COM references being manipulated in same way each time it is run. I fear the problem will just be something to do with the local install of Excel. It might help if you can reproduce it on another box, or even try and reproduce it on the same box using something like wscript. <side-note> I recently had a problem where firefox would regularly hang and need to be force stopped. After waiting for update to fix the problem, I bit-the-bullet and attached a debugger to a hanging instance to see if I could report a reasonable firefox bug on the issue. The stack frames led me to the conclusion opengl (or something like it) was being used. On a whim I looked for a new video driver and magically the problem went away. ie, a driver actually caused one single application on my box to look very much like that app - and that app alone - had a strange bug - but it turned out to be nothing to do with the application at all. Your problem might be similar. Also, FWIW, it isn't a "windows error" as such - it is simply an excel crash which Windows Error Reporting is taking action on. A fairly subtle difference, but the point is that the crash is "simple", constrained to Excel itself and not something serious that is upsetting Windows. Not that that helps you though... Mark _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
