Summary:
Following installation of Microsoft security patches and computational
chemistry files that include .NET framework a problem starting
processing.exe appears.

Details:
On startup of processing-0092 a dialog appears that states:
processing.exe - Application Error
"The exception unknown software exception (0xc00000fd) occurred in the
application at location 0x77fcc2ae.
Click on OK to terminate the program
Click on CANCEL to debug the program.

After a lag, processing starts up, but does not function normally on all
examples.

Actions Taken:
1) Remove security patches. Did not eliminate Application Error dialog.
2) Remove computational chemistry computational chemistry beta test files
including .NET framework. Did not eliminate Application Error Dialog.
3) Check system completely for worms and viruses. None found.
4) Reinstall processing-0092. Did not eliminte Application Error dialog.
5) Run malicious software removal tool. Did not eliminate Application Error
dialog.
6) Attempt to debug error stock Visual C++ environment that actives on
"CANCEL".
reports: No primary platforms are available. The build system will be
disabled. It is likely that a build system 'add-on' platform (.pkg)
installed by Setup, failed to load.

edit]
Application Error - processing.exe

edit]
Application Error - processing.exe

This is the first of two error dialogs that have appeared.

More Actions Taken:
memory test. PASSED.
CPU test PASSED.
VIDEO test PASSED.
GRAPHICS CARD test PASSED.


Application Error Dialog box still appears on startup.

have you read the faq item titled "processing won't start"?
http://processing.org/faq/bugs.html#wontstart

edit]
Processing0092LaunchBug01.gif - Showing character alteration.

edit]
Processing0092LaunchBug02.gif - Error calling Shell Execute()

edit]
Processing0092LaunchBug03.gif - Unknown software exception.

Workaround Actions to Solve Processing Startup Bug 133:

1) duplicated the run.bat file
2) named it processing.bat
3) created a shortcut to processing.bat
4) copied the icon from processing.exe to processing.bat shortcut
5) dragged the processing.bat shortcut to the Quick Launch Toolbar.
6) Processing now launches without error.

I have appended a copy of the image that illustrates this process as an
attachment.

edit]
Workaround to startup bug using iconified processing.bat

Dear Alan –

Thanks for your patience and diligence in following up on M/S support
incident SRZ050817001229

This incident followed a "perfect storm" that involved:
• A set of Microsoft security updates,
• A set of beta tests involving Cambridge Chem3D software
• Processing.exe - an excellent visualization tool developed at MIT.
• Some bad internet traffic on the firewall.

To show my appreciation, I want to give you an accurate report of what
happened.
This is in the hope that other users can avoid similar problems.
Some of the problems I encountered were quite serious.
I have worked around them and disclose the workaround at the end.

I will be as brief as possible, but some explanation is necessary, as the
"storm" was complex.

Background
1) I am an experienced software engineer and NASA veteran, trained in
computer science at the University of Utah. I am currently developing
graphics algorithms for the display of cellular processes to help
understand cancer.

2) I provide aid to disadvantaged people who only have Windows98 computers.
Often their computers don't work anymore due to viruses, worms, and spyware.
I am grateful for your anti-spyware initiative, and hope it will extend to
this community of disadvantaged users.

3) I am disciplined about computer security and
• use a router to isolate myself from the internet.
• use a software firewall to examine incoming traffic.
• run Norton 2005 SystemWorks™ professional in real time to detect viruses,
and check inbound and outbound email.
• keep my system equipped with the latest Windows 2000 Professional updates
• run Microsoft antiSpyware.

4) As a result, I almost never have to contact Microsoft. In the past, when
I have, my expectations are usually met or exceeded.

Last Tuesday, following installation of a Microsoft security update, my
computer refused to launch the tool processing.exe. This was a serious blow
to my work.

When I tried to report the event, I was directed to a Microsoft support
page that indicated that I was going to be charged $245 for phone or $99
for email support. I can say with no malice now, that I found that
infuriating. The problem appeared to have been caused by a Microsoft update.

The Perfect Storm

A few days before the incident, there had been problems with the internet
connecting my computer to my home office network.

First thing Tuesday morning, I had been prompted to install a set of
Microsoft security updates that had just arrived to combat a set of related
worms on the internet. I installed these immediately after reviewing the
technical details, as is my standard practice.

That morning, I had done a beta-test run for my friends at Cambridge
Software in Boston. I test their chemistry software as a matter of
routine.It is an OpenGL-based 3D chemistry system. I test, and I report to
them.

I finished my beta-testing, and after that, when I went to start my
java-based "processing.exe" program, I received the attached dialog that
had never appeared before. It would not go away no matter WHAT I did.

I repeated the test, and noted that going into Visual C++ did not help fix
the problem as no block information loaded.

Screen captures also failed during this time, so more than one program
appeared to be affected. (I use SnagIt™ from TechSmith™, an excellent product.)

Because there was no apparent reason for this error, I started
backtracking, removing the security updates one by one, and removing the
beta software I had been testing.
This took a long time and I was meticulous about it.

Backtracking and rebooting did not solve the problem. I checked my BlackIce
personal firewall. There was a lot of questionable traffic coming to my
doorstep.

Running multiple Norton scans indicated that my registry was intact and
that I had no apparent viruses or worms. However, the error remained. My
work was stopped.
By late in that evening I was at my wit's end. It was then that I was
directed to the Microsoft page requiring $249/$99 for ANY support.

The next day I reported this bug to the processing experts (bug 133 on the
processing.org site)
I was informed I could change the startup procedure and fix the program.
I implemented the fix and logged my modifications to the bug 133.

This worked well enough. I reinstalled the security updates as a precaution
against infections, and am currently reinstalling the Cambridge beta software.

Theory of the Incident

My current theory is that:

• Installing the security updates changed the way programs are executed on
my computer, particularly processing.exe.
• The beta testing was a "red herring" – an unrelated coincident activity.
• The firewall traffic was also unrelated.

At the current time, my computer appears to be functioning normally.

Thanks for your patience. I hope this can help someone else.

Hi Mr. Warren,

First, thank you very much for sharing such detailed information with me
which allow me to better help you.

Based on the error message (I pasted it below for easy reading), this is an
application crash - a typical AV (Access Violation) issue meaning that the
instruction cannot access the memory referenced either because the address
is invalid or it is not-accessible.




Our system has a built-in feature called Dr.Watson which will generate a
dump file (which includes the full memory space of the process at the time
when the error occurs) for a postmortem analysis in order to trace the root
cause. Two files will be included in the report - Dr.Watson log file and
the user.dmp file. To access the files, please click Start >> Run, input
drwtsn32 and click OK. Take a note of the path there and you can then use
it to find the files (the path varies between different OS, e.g. 2000 and
XP). Whether the files are generated depends on your configuration. The
default setting is to generate the files. In addition, you should also see
an error log in the Application Log, the source is "Drwatson", so that you
can determine the time and date of the occurrence afterwards.


To analyze the dump file (user.dmp) you need to download a tool called
Windbg which is available at
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
<http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx> . To be
able to use the tool, you also need to configure symbols. Please follow the
instructions at
http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx
<http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx>


Windbg is a sophisticated debugging tool and has been improved a lot
recently. To get started using this tool, please read the built-in help
file and other information at the Windbg web portal:
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
<http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx>


I noticed you reasoned "Installing the security updates changed the way
programs are executed on my computer, particularly processing.exe." I am
afraid that I cannot agree with you. What the security updates do is to
update the binary files (.exe file, .dll files) and all the fixes (or
patch) is integrated into the binary files, which is also reflected by the
file version. Therefore after you rolled back (remove updates via
Add/Remove Programs applet) the updates, the system should be restored to
the status before the application of the updates. Thus, your conclusion
seems to be unfounded, unless the files are not successfully rolled back.
You may check the files version to double confirm that. The file version
information can be obtained from the technical details section of the
document for each update.


If I would have to guess what may have happened, I would say that was just
a coincidence - the application happened to crash after you applied the
updates.

In order to trace what exactly happened, we need to analyze the dump file.
If you would like us to take a look at the dump file, we will be happy to
do so, but I would like to give you an heads-up, most likely we will be
able to see what processing.exe was doing at the time of crash but if we
need to dig deeper we need the sympbol and source code of that program.


That is to say we need to involve the program vendor. But at least we can
do some work of our part - from the system perspective.


Let me know how you would like to proceed.

Thanks.

Regards,
Alan

Hi Mr. Warren,

First, thank you very much for sharing such detailed information with me
which allow me to better help you.

Based on the error message (I pasted it below for easy reading), this is an
application crash - a typical AV (Access Violation) issue meaning that the
instruction cannot access the memory referenced either because the address
is invalid or it is not-accessible.




Our system has a built-in feature called Dr.Watson which will generate a
dump file (which includes the full memory space of the process at the time
when the error occurs) for a postmortem analysis in order to trace the root
cause. Two files will be included in the report - Dr.Watson log file and
the user.dmp file. To access the files, please click Start >> Run, input
drwtsn32 and click OK. Take a note of the path there and you can then use
it to find the files (the path varies between different OS, e.g. 2000 and
XP). Whether the files are generated depends on your configuration. The
default setting is to generate the files. In addition, you should also see
an error log in the Application Log, the source is "Drwatson", so that you
can determine the time and date of the occurrence afterwards.


To analyze the dump file (user.dmp) you need to download a tool called
Windbg which is available at
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
<http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx> . To be
able to use the tool, you also need to configure symbols. Please follow the
instructions at
http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx
<http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx>


Windbg is a sophisticated debugging tool and has been improved a lot
recently. To get started using this tool, please read the built-in help
file and other information at the Windbg web portal:
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
<http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx>


I noticed you reasoned "Installing the security updates changed the way
programs are executed on my computer, particularly processing.exe." I am
afraid that I cannot agree with you. What the security updates do is to
update the binary files (.exe file, .dll files) and all the fixes (or
patch) is integrated into the binary files, which is also reflected by the
file version. Therefore after you rolled back (remove updates via
Add/Remove Programs applet) the updates, the system should be restored to
the status before the application of the updates. Thus, your conclusion
seems to be unfounded, unless the files are not successfully rolled back.
You may check the files version to double confirm that. The file version
information can be obtained from the technical details section of the
document for each update.


If I would have to guess what may have happened, I would say that was just
a coincidence - the application happened to crash after you applied the
updates.

In order to trace what exactly happened, we need to analyze the dump file.
If you would like us to take a look at the dump file, we will be happy to
do so, but I would like to give you an heads-up, most likely we will be
able to see what processing.exe was doing at the time of crash but if we
need to dig deeper we need the sympbol and source code of that program.


That is to say we need to involve the program vendor. But at least we can
do some work of our part - from the system perspective.


Let me know how you would like to proceed.

Thanks.

Regards,
Alan

Hi Van,

I have finished analyzing the dump file. It is clearly a third-party
program's fault. I pasted the debug log below for your reference:

Debug Log
================
Microsoft (R) Windows Debugger Version 6.6.0000.1
Copyright (c) Microsoft Corporation. All rights reserved.



Loading Dump File [C:\cases\SRZ050817001229\crash.dmp]
User Dump File: Only application data is available

Windows 2000 Version 2195 UP Free x86 compatible
Product: WinNt
Debug session time: Thu Aug 25 11:31:45.546 2005 (GMT+8)
System Uptime: 0 days 11:38:18.255
Process Uptime: not available
Executable search path is:
...........
(8fc.5f8): Access violation - code c0000005 (!!! second chance !!!)
eax=32393030 ebx=000003d7 ecx=6f727000 edx=003f2400 esi=003f0000 edi=003f0548
eip=77fcc024 esp=0022fc28 ebp=0022fdf4 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
ntdll!RtlAllocateHeap+0x649:
77fcc024 8901 mov [ecx],eax ds:0023:6f727000=????????
0:000> kv
ChildEBP RetAddr Args to Child
0022fdf4 78001532 003f0000 00000000 00000140 ntdll!RtlAllocateHeap+0x649
(FPO: [Non-Fpo]) (CONV: stdcall) [D:\nt\private\ntos\rtl\heap.c @ 1868]

0022fe34 780014cf 0000013c 780014b8 0000013c msvcrt!_heap_alloc+0xeb (CONV:
cdecl) [f:\9844\vc61\crtbld\crt\src\malloc.c @ 207]

0022fe3c 780014b8 0000013c 00000000 004014cb msvcrt!_nh_malloc+0x10 (FPO:
[2,0,0]) (CONV: cdecl) [f:\9844\vc61\crtbld\crt\src\malloc.c @ 113]

*** ERROR: Module load completed but symbols could not be loaded for
processing.exe
0022fe48 004014cb 0000013c 003f23a0 003f23d0 msvcrt!malloc+0xf (FPO:
[1,0,0]) (CONV: cdecl) [f:\9844\vc61\crtbld\crt\src\malloc.c @ 54]

WARNING: Stack unwind information not available. Following frames may be
wrong.
0022fef8 0040190a 00400000 00000000 00232b46 processing+0x14cb
0022ff78 004011e7 00000001 003f23b8 003f2d08 processing+0x190a
0022ffb0 00401238 00000001 00000009 0022fff0 processing+0x11e7
0022ffc0 7c59893d 0070005c 006f0072 7ffdf000 processing+0x1238
0022fff0 00000000 00401220 00000000 000000c8 KERNEL32!BaseProcessStart+0x3d
(FPO: [Non-Fpo]) (CONV: stdcall)
[e:\nt\private\windows\base\client\support.c @ 504]

Note: it's an AV issue, not "stack overflow" as illustrated with the
screenshot in your last email.

Based on my experience, what the program (processing.exe) did was to do a
string copy and it requested some memory via the runtime library
msvcrt.dll. Possible root cause is that the program miscalculated the
address and provided an invalid address, so the AV problem occurred and the
program then crashed.

At this point we are not able to dig further into the problem as we do not
have the source code and the symbol files. You need to send the dump file
to the program vendor and they are the right person to help you figure out
what's wrong with their code.

Thanks.

Regards,
Alan

Hi Van,

I have finished analyzing the dump file. It is clearly a third-party
program's fault. I pasted the debug log below for your reference:

Debug Log
================
Microsoft (R) Windows Debugger Version 6.6.0000.1
Copyright (c) Microsoft Corporation. All rights reserved.



Loading Dump File [C:\cases\SRZ050817001229\crash.dmp]
User Dump File: Only application data is available

Windows 2000 Version 2195 UP Free x86 compatible
Product: WinNt
Debug session time: Thu Aug 25 11:31:45.546 2005 (GMT+8)
System Uptime: 0 days 11:38:18.255
Process Uptime: not available
Executable search path is:
...........
(8fc.5f8): Access violation - code c0000005 (!!! second chance !!!)
eax=32393030 ebx=000003d7 ecx=6f727000 edx=003f2400 esi=003f0000 edi=003f0548
eip=77fcc024 esp=0022fc28 ebp=0022fdf4 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
ntdll!RtlAllocateHeap+0x649:
77fcc024 8901 mov [ecx],eax ds:0023:6f727000=????????
0:000> kv
ChildEBP RetAddr Args to Child
0022fdf4 78001532 003f0000 00000000 00000140 ntdll!RtlAllocateHeap+0x649
(FPO: [Non-Fpo]) (CONV: stdcall) [D:\nt\private\ntos\rtl\heap.c @ 1868]

0022fe34 780014cf 0000013c 780014b8 0000013c msvcrt!_heap_alloc+0xeb (CONV:
cdecl) [f:\9844\vc61\crtbld\crt\src\malloc.c @ 207]

0022fe3c 780014b8 0000013c 00000000 004014cb msvcrt!_nh_malloc+0x10 (FPO:
[2,0,0]) (CONV: cdecl) [f:\9844\vc61\crtbld\crt\src\malloc.c @ 113]

*** ERROR: Module load completed but symbols could not be loaded for
processing.exe
0022fe48 004014cb 0000013c 003f23a0 003f23d0 msvcrt!malloc+0xf (FPO:
[1,0,0]) (CONV: cdecl) [f:\9844\vc61\crtbld\crt\src\malloc.c @ 54]

WARNING: Stack unwind information not available. Following frames may be
wrong.
0022fef8 0040190a 00400000 00000000 00232b46 processing+0x14cb
0022ff78 004011e7 00000001 003f23b8 003f2d08 processing+0x190a
0022ffb0 00401238 00000001 00000009 0022fff0 processing+0x11e7
0022ffc0 7c59893d 0070005c 006f0072 7ffdf000 processing+0x1238
0022fff0 00000000 00401220 00000000 000000c8 KERNEL32!BaseProcessStart+0x3d
(FPO: [Non-Fpo]) (CONV: stdcall)
[e:\nt\private\windows\base\client\support.c @ 504]

Note: it's an AV issue, not "stack overflow" as illustrated with the
screenshot in your last email.

Based on my experience, what the program (processing.exe) did was to do a
string copy and it requested some memory via the runtime library
msvcrt.dll. Possible root cause is that the program miscalculated the
address and provided an invalid address, so the AV problem occurred and the
program then crashed.

At this point we are not able to dig further into the problem as we do not
have the source code and the symbol files. You need to send the dump file
to the program vendor and they are the right person to help you figure out
what's wrong with their code.

Thanks.

Regards,
Alan

perhaps this hasn't been documented properly in the faq, but there are several known
crashing errors like this that are known bugs in processing.exe. some of it is outlined here:
http://processing.org/faq/bugs.html#wontstart

chances are you probably have something weird in your PATH or CLASSPATH that changed
with the installation. if not, it's just something else i need to track down.

but in general, please keep in mind this is beta software. things are going to break a lot.

this should be ironed out in more recent releases.