Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. COM
  4. Error handling events in wscript

Error handling events in wscript

Scheduled Pinned Locked Moved COM
helpc++sysadminquestion
2 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • P Offline
    P Offline
    particle2k
    wrote on last edited by
    #1

    hello, i have an local server application exposing some objects with dispinterface events. and i have a simple .vbs file which creates an object instance, and connects the event interface and releases everything. Set App = CreateObject( "Server.App" ) WScript.connectObject App, "app_" WScript.DisconnectObject App set App = Nothing wscript.quit then the wscript crashes with an access violation. if i remove the connectobject line, the wscript terminates without error. seems like the wscript crashes inside the quit method, an messagebox right in front on the quit is displayed correctly. if i connect the event interface from a c++ client, with atladvise, atlunadvise, everything works, i get no error there. what could be the problem there? where can i search why the wscript crashes? if have no source for the wscript. the advise and unadvise marshalls the interface into a stream to make it accessable from any thread. ... error checking LPSTREAM pStream = 0; hRes = CreateStreamOnHGlobal( 0, TRUE, &pStream ); if ( SUCCEEDED( hRes ) ) { hRes = CoMarshalInterface( pStream, iid, p, MSHCTX_LOCAL | MSHCTX_INPROC | MSHCTX_NOSHAREDMEM, 0, MSHLFLAGS_TABLESTRONG ); } ... store stream and return cookie. maybe there is the problem, i also tried with MSHCTX_INPROC only, but the same error occurred. thanks in advance enrico

    E 1 Reply Last reply
    0
    • P particle2k

      hello, i have an local server application exposing some objects with dispinterface events. and i have a simple .vbs file which creates an object instance, and connects the event interface and releases everything. Set App = CreateObject( "Server.App" ) WScript.connectObject App, "app_" WScript.DisconnectObject App set App = Nothing wscript.quit then the wscript crashes with an access violation. if i remove the connectobject line, the wscript terminates without error. seems like the wscript crashes inside the quit method, an messagebox right in front on the quit is displayed correctly. if i connect the event interface from a c++ client, with atladvise, atlunadvise, everything works, i get no error there. what could be the problem there? where can i search why the wscript crashes? if have no source for the wscript. the advise and unadvise marshalls the interface into a stream to make it accessable from any thread. ... error checking LPSTREAM pStream = 0; hRes = CreateStreamOnHGlobal( 0, TRUE, &pStream ); if ( SUCCEEDED( hRes ) ) { hRes = CoMarshalInterface( pStream, iid, p, MSHCTX_LOCAL | MSHCTX_INPROC | MSHCTX_NOSHAREDMEM, 0, MSHLFLAGS_TABLESTRONG ); } ... store stream and return cookie. maybe there is the problem, i also tried with MSHCTX_INPROC only, but the same error occurred. thanks in advance enrico

      E Offline
      E Offline
      Erik Juhl
      wrote on last edited by
      #2

      Can you check the error within your vbs? I have had to debug vbscript before and what I had to do was add the line "on error resume next" and then in your case add a error check right after the call to connectobject. I typically check if err.number <> 0 then msgbox err.number & " " & err.description. That depends on the security context your script is running under. For debugging, I usually isolate the suspect script into a solitarty script file that I can execute from my desktop, thus inheriting my security rights and msgbox fires with the info I want.

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups