Skip to main content

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



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”.

Popular posts from this blog

Test connection to remote SQL Server Database from an Application server

While aiming to test whether a SQL connection is succeeding between an Application server and a remote Database Server, it is often not possible to install SQL Server Management Studio (SSMS) or Microsoft Command Line Utilities (MsSqlCmdLnUtils) due to the locked down nature of the targets, particularly in test and production environments. A lightweight approach that worked for me recently, makes use of components that have been a part of windows boxes for a long time, albeit different levels of database driver support as the components have evolved, the Microsoft Data Access Components (MDAC). MDAC provide a Universal Data Link, which can be configured using a common user interface for specifying connection properties as well as testing the connection.  Data Link properties dialog box Get started – Create a simple text file • Simply create a  .txt file anywhere on your system rename the extension to .udl • Double click the Un

Windows Azure Storage Emulator failed to install

CodeProject Windows Azure Storage Emulator failed to install When attempting to install a new version of the Azure Storage Emulator either as a separate installation package or automatically as part of an Azure SDK update, you may run into an error message which states the storage emulator has failed to install. This can occur using the Web Platform Installer (WebPI), NuGet Package Manager or when performing the install manually. Below is the message received using the WebPI.   Storage Emulator Background  (optional reading) The windows azure storage emulator executable lives under the Microsoft SDKs directory as shown below: Configuration If we take a quick look inside the WAStorageEmulator.exe.config file we can see each of the storage services pointing to local service endpoints. <StorageEmulatorConfig>     <services>       <service name=" Blob " url="http://127.0.0.1:10000/"/>       <service

Azure DevOps Authorisation

Managing whether an identity has access to a given  service, feature, function, object, or method in Azure DevOps comes down to authorisation. Fortunately, by default, the DevOps permissions are set in such a way to enable you to focus on the job at hand, DevOps. Loosely translated this means 'don't get in my way'. My experience is that the Azure DevOps team have done a good job at this, enabling you to crack on developing, building, testing and releasing without much hindrance. Working with relaxed permissions is great when you are the owner and possibly either a one man band or small team but as soon as we need to consider larger teams, varying roles with approvals and degrees of access, authorisation becomes a real concern. I was recently involved in a project utilising offshore developers where trust was a concern and a number of specific teams handling specific roles needed to come together to approve a set of pipelines.  This article is a pick of findings a