Debugging .Net Components called from Python, being run from a Batch Script, executed by the Windows Task Scheduler (Part 2)
In Part 1 We identified the problem i was recently asked to investigate and looked at getting some output from the batch script being run by the Windows Task Scheduler. As this was a production environment, there was little that could be modified and remote debugging wasn't an option.
In this part 2 post, we will continue to fault find touching on the Python and .Net components i mentioned previously and get to the point where the problem is fully identified and subsequently fixed without any changes made to the production code.
Having started to receive output, the next step was to make some sense of it.
The first thing i did was wrap the area of interest in the python script with a try catch
try:
except:
print "exception: %s" % (sys.e
PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software.
Last but not least and probably the less intrusive way of testing SQL connectivity is by use of Universal Data Link files (.UDL). This method does not require the installation of a telnet client or has as many steps as the “System DSN” method and support for this method is built into every windows version. You can delete the file afterwards to “clean-up” the system. Right-click anywhere on your desktop and select “New”, then “Text Document”.
Having started to receive output, the next step was to make some sense of it.
The first thing i did was wrap the area of interest in the python script with a try catch
1) some generic exception try: except: print "Exception: %s" % (sys.exc_info()[0]) Exception: Query Error This was at least a start in that it looked database related at this point The next task was to identify the type of exception being thrown A call was being made to a .Net component which looked to be instantiating a database repository. 2) .Net exception import clr except Exception, e: print type(e).__name__ print type(e.clsException).__name__ log.Write("exception - (generic) %s" % sys.exc_info()[0]) print "exception - (generic) %s" % (sys.exc_info()[0]) 3) fortunately an import at the top of the script gave me a hint as to the class library being used for the database repo. If this had not existed i would have turned to ilspy to take a peek at the assemblies in the application. It was the namesace i was most interested in using, it din't take long to ilspy to find the class library the import the specific exception type from the .net assembly from MCorp.Util.DB import DBException except DBException, d: print type(d).__name__ print type(d) print d.Message print d.StackTrace this still reported a 'query error' so i suspected the 4) inner exception if d.InnerException != None: print d.InnerException.Message print d.InnerException.StackTrace Login failed for user 'C5WebFrontendRWSTG'. In order to verify what the correct microsoft data link it uses to create a remote
try:
except:
print "exception: %s" % (sys.e
PsExec is a light-weight telnet-replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software.
Last but not least and probably the less intrusive way of testing SQL connectivity is by use of Universal Data Link files (.UDL). This method does not require the installation of a telnet client or has as many steps as the “System DSN” method and support for this method is built into every windows version. You can delete the file afterwards to “clean-up” the system. Right-click anywhere on your desktop and select “New”, then “Text Document”.
Also checkout some other musings via my blazor.net and azure blog here carlrandall.net
Feel free to contact me via my site AssemblySoft to discuss any ways i can help with your next project...
References:
Feel free to contact me via my site AssemblySoft to discuss any ways i can help with your next project...