I noticed the same problem - crash on exit.
It happens in a glDeleteTextures() call. At this point, the OpenGL context seems
not to exist anymore. Any other calls to OpenGL failed as well. 
For my own purposes, I removed the call to glDeleteTextures() and everything
works fine now.
I think, the order in which the OpenGL context and the objects are destroyed is
messed up, but I haven't further investigated in the matter.

This seems to be a problem with every stream program on Windows.  The sample
code on the Sh Wiki also causes this crash.

This has apparently nothing to do with the "particles flying into space" bug
(issue320).

The crash in particles is different.  I get the following error message:
 NVOpenGLPbuffer: ShParticleExample.exe - Application Error
 The exception unknown software exception (0xc0000005) occured in the
application at location 0x5e8d532e.

r3523 should fix the issue with the Binding example.  I have removed the
offending new/delete calls since that stuff is now handled by the
(non-windows-specific) backend instantiation code.

I'm having the same problem.
I noticed that the arb backend's destructor is being called twice, recursively.
The outer destruction starts while DLL_PROCESS_DETACHing, while the other 
spawns while removing the backend from the backend's list (destruction of the 
shared pointer inside the static map of backends 
ShBackend::m_instantiated_backends).
The problem could be avoided either by converting the ShPointer<ShBackend> in 
BackendMap to a standard ShBackend* (this will solve THIS problem, but more 
will arise from the others ShPointer<ShBackend> around).
Another, more complex solution could be letting ShBackend manage the memory and 
add some functions to register, instantiate and deinstantiate the backend onto 
ShBackend, and replacing the new/delete couple with.
Anyway, the instantiation/deinstantiation of a Backend is a bit confused.
I think that the thing will broke anyway if you run two applications sharing 
the same dlls.
It's not very clear to me if a backend-derived class should be a per process 
singleton, a cross process singleton or just an object as the others (I'm 
referring to the arb backend in particular, but I think this will apply to the 
other backends, too):
By the code in dllmain it looks like a per process singleton (every attached 
process create a new backend). 
On the other hand, the code in ShBackend seems to link the life of the only 
ArbBackend to the life of the libsh dll, so it looks like a cross process 
singleton, since the registration is linked to construction of a subclass and 
deregistration of linked to destruction of a subclass.
On the other hand again (third one?) the shBackend_libsharb_instantiate can be 
used to create another backend, and I can't catch this one.
Is this a design issue, or it's just me not being able to catch the 
instantiation mechanism?

Simply run the particle or the binding example, press space so that the
particles/polygon start moving.  Then press 'q' to quit.  You will get an error
message like:
  "The instruction at 0x5ed0530e referenced momory at 0x0000051c.  The memory
could not be read."