Debugging iLogic under Windows 10

A while ago I posted on debugging methods using SysInternals DebugView.  Well, this past week IT upgraded my machine from Windows 8.1 to 10 and with a few small exceptions things have been working well.

Until I went to begin debugging an iLogic rule and while DebugView launched fine and loaded my existing filters like a champ, it just sat there with a blank look on it's face.

I'd have sooner given up my right arm than agree to forego DebugView on the new platform.  I immediately reached out to a team member who I knew had been on Win10 for a while and uses DebugView daily.  "No problem here", he states...crap, the problem is local.  Or maybe not...


Like most when faced with a quandary of monumental proportion, I did a Google search and came up with the following post on Sysinternals forum:

Topic: DbgView and Windows 10

The first post almost broke my heart.  Not compatible with Windows 10?  Are you kidding me?

Fear not, keep reading...

About 2/3's down the page alanadams had an interesting comment about his experience with the problem. It seems that DebugView silently installs a .sys file in the ...\System32\Drivers folder.  Once there it seems that Windows keeps it from being written again because Windows says the driver is already running.

The solution?  Rename the original dbgv.sys file, then restart DebugView.  For some reason that seems to pacify Windows and lets DebugView run normally.  Who knew?

alanadams claimed, (at least for him), that this only fixes DebugView for that session and the step may need to be repeated, but for me at least DebugView continues to run even after several restarts including reboots.

I also run DebugView as Administrator just because I can, not necessarily because I need to.

So, hopefully you're like my fellow co-worker and DebugView works right out of the box, but if not you now have something to potential ease the pain.

Happy Coding,

Taking the mystery out of debugging

One of the complaints I hear most often from clients and other iLogic developers is the inability to debut iLogic code from within the iLogic IDE.  I've shared similar frustrations as I'm generally a brute force kind of programmer...write some code, run it, see what breaks, fix the error, then plunge ahead again.

Don't get me wrong, I ALWAYS plan out the workflow and general design criteria of what my code needs to do ahead of time, but sometimes the semantics are either not important or completely apparent before I begin writing.

I've come to rely on a few 3rd party tools to aid my debugging process.

Method #1: Utilize the built in debugger to decipher syntax errors

An often overlooked method of debugging iLogic code is the iLogic interface itself.  When asked to run code that generates an un-handled exception iLogic will throw a message box like this:

 

Not terribly informative.  But have you ever taken a look at the More Info tab?  You'll see a much more descriptive display of just exactly what the problem is.

Ah,...I declared a variable as a an Integer then tried to fill it with a string.

Dim i As Integer = "string"

Granted, a silly freshman mistake, but after all, this was meant as an simple example.
Don't be too quick to dismiss the simplicity of the built-in compiler debugger.

Method #2: DebugView

DebugView is a free tool distributed by Microsoft Technet.  Usage is described on Autodesk's Manufacturing DevBlog: Debug iLogic Code.  Adam Nagy does a great job of describing the basic features of DebugView and how to set it up for tracing errors in an iLogic rule.

DebugView has some really nice features such as being able to add custom filters giving a very colorful output, highlighting specific lines.  Here I've added a filter containing the text "iLogicErr".  Anytime that DebugView reads a Trace statement containing the phrase "iLogicErr" it will highlight the line making in my case errors quickly identifiable. 

In this instance I've used a Try/Catch block like this:

Try

   ‘your code goes here  

Catch ex As Exception

    Trace.TraceError("iLogicErr: #2")

End Try

Download DebugView here.

Structure the suspect code, (wrap the whole rule if necessary), as follows:

Try

   ‘your code goes here  

Catch ex As Exception

    Trace.TraceError("iLogic: " & ex.Message)

End Try

This will pass back the actual the error message that was encountered, either by Inventor or Windows.  You may still need the rune stone to figure out the cryptic generic message that iLogic throws, but you'll be in a much better position to correctly handle the exception like this:

Catch ex As Exception

    Trace.TraceError("iLogic: " & ex.Message)

    Exit Sub

    ' Goto Foo

    ' provide other useful user feedback

End Try

As an added bonus, check out my associated abbreviated DebugView article here:

Taking the mystery out of debugging

Method #3: Visual Studio
The final method takes a little more effort to set up, but overall does give you more verbose and complete feedback when debugging code.

You might be thinking that wait a minute, I'm writing iLogic code, why do I need Visual Studio?  Well, I remind you that iLogic is running on top of the Microsoft .NET Framework and the iLogic IDE is really a sub-set or wrapper around some build in .NET functionality.

This built in functionality comes to our aid in the fact that that .NET calls and functions work "EXACTLY" the same in iLogic that they do in iLogic.

First, you must have a copy of Visual Studio.  I always like free and recommend using Microsoft's Express version of Visual studio.  You can download Visual Studio Express Desktop 2015 here.  VS Express Desktop 2013 is also available on the same page.  Download your preferred version and install.

To set up your debug environment start a new VB Console Application project.  You can save it using any name and location you wish.

Next you'll probably want to add a reference to Inventor so that you can take advantage of Intelli-Sense within VS.  To do this Right click on References in the Solution Explorer and browse to "C:\Program Files\Autodesk\Inventor 201(n)\Bin\Public Assemblies\Autodesk.Inventor.Interop.dll"

Next add an Imports Inventor at the top of your console app Main Module.  Starting to look familiar?

We're really working with our code at an Inventor API level, but with a few syntax changes Visual Studio can provide a superb debugging tool.

Next let's add some functionality to our code.

Time to debug!  Add a break point by clicking in the left margin.  You'll see a little red dot appear indicating where the code will stop.

We can step into this code by selecting the Start button on the main toolbar.  The code will execute and run, stopping on our break point.  And here comes the sweetness that is Visual Studio, we can step through each line, hovering over variables and objects to determine values immediately, all while the code is running. 

You can step through each line by pressing F11 or selecting the Step Into button on the Debug toolbar, (if the Debug toolbar is not visible GoTo View>Toolbars>Debug).

After stepping past the line where we declare ThisApplication, I can hover the mouse over ThisApplication and by drilling down several levels I can see this:

Powerful stuff!  While it takes a little to set up, 'most' iLogic code can quickly be converted to run inside VS.  In fact, to make my life easier I keep a VS project on my development machine that's already set up with the Inventor.Interop reference so all I have to do is plug in my problem code and set to work debugging by stepping through the code.

I hope you find this article useful.

Happy Coding!