It’s really intriguing how very minute configurations can have the potential of bringing the entire project development to a grinding halt. In this article, I would like to walk you through one such strange behaviour I noticed on one the Enterprise Customer’s Development Environment.

When trying to create a New SSIS package using Business Intelligence Studio 2008 on a Windows 2003 Server Enterprise Edition (x86) machine , there was error thrown by the Package designer :

"Microsoft Visual Studio is unable to load this document.  Exception has been thrown by the target of the invocation."

 

clip_image002

 

When I checked the Event viewer logs, I could not find any error/ warning messages being recorded for this behaviour.

I decided to get started by installing the Debugging tools for Windows (32bit) on customer’s machine. I knew I would also need to download the PSSCOR2 debugging extension. (The very idea of this was to save customer’s time in uploading those huge crash dump files to our FTP location)

Following there, here’s how I would list my approach to troubleshoot the issue:

  • Once the Debugging tools for Windows were installed, I opened a command prompt and traversed to the location where the debugging tools were installed.

  • Started the Business Intelligence Studio 2008 and opened the task manager to get the Process ID for the DEVENV.exe. In this scenario , the PID was 456

  • In the Command Prompt , typed in the following to capture the crash dumps for the error that will be seen on the BIDS 2008 Designer Screen :

              adplus -crash -p 456 - fullonfirst

  • As soon I hit enter, the debugger was attached to the DEVENV.exe process and started monitoring it for any first chance exceptions that might be raised.

  • Now going back to the BIDS 2008, Tried to create a New SQL Server Integration Services Project.

  • Within a few seconds, the error message was shown on the Visual Studio Screen.

  • Closed the BIDS 2008 and looked into the Debugging tools for Windows folder. aaah ! there were dump files captured in there.

Now that I had the dump files, I opened Windbg and loaded the PSSCOR2 Extension after loading the dump file. Here's what happened next:

First task was to print the exception using the !pe command :

0:000> !pe
Exception object: 0481e76c
Exception type: System.Reflection.TargetInvocationException
Message:
Exception has been thrown by the target of an invocation.
InnerException: System.ArgumentException, use !PrintException 048141e4 to see more
StackTrace (generated):
<none>
StackTraceString: <none>
HResult: 80131604

 

I was interested to see what would the Dump Object on 048141e4 reveal , hence

0:000> !do 048141e4
Name: System.ArgumentException
MethodTable: 6de97354
EEClass: 6dc64294
Size: 76(0x4c) bytes
(C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
6deb0ae8  40000b5        4        System.String  0 instance 00000000 _className
6deaff5c  40000b6        8 ...ection.MethodBase  0 instance 00000000 _exceptionMethod
6deb0ae8  40000b7        c        System.String  0 instance 00000000 _exceptionMethodString
6deb0ae8  40000b8       10        System.String  0 instance 0481e5c0 _message
6deaa444  40000b9       14 ...tions.IDictionary  0 instance 00000000 _data
6deb0c7c  40000ba       18     System.Exception  0 instance 00000000 _innerException
6deb0ae8  40000bb       1c        System.String  0 instance 00000000 _helpURL
6deb0704  40000bc       20        System.Object  0 instance 0481e700 _stackTrace
6deb0ae8  40000bd       24        System.String  0 instance 00000000 _stackTraceString
6deb0ae8  40000be       28        System.String  0 instance 00000000 _remoteStackTraceString
6deb2d34  40000bf       34         System.Int32  1 instance        0 _remoteStackIndex
6deb0704  40000c0       2c        System.Object  0 instance 00000000 _dynamicMethods
6deb2d34  40000c1       38         System.Int32  1 instance -2147024809 _HResult
6deb0ae8  40000c2       30        System.String  0 instance 00000000 _source
6deb33b0  40000c3       3c        System.IntPtr  1 instance        0 _xptrs
6deb2d34  40000c4       40         System.Int32  1 instance -532459699 _xcode
6deb0ae8  40001ec       44        System.String  0 instance 00000000 m_paramName

 

Next, Dump Object 0481e5c0 to view the exception message

0:000> !do 0481e5c0
Name: System.String
MethodTable: 6deb0ae8
EEClass: 6dc6d65c
Size: 130(0x82) bytes
(C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String:
Font 'Verdana' does not support style 'Regular'.
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
6deb2d34  4000096        4         System.Int32  1 instance       57 m_arrayLength
6deb2d34  4000097        8         System.Int32  1 instance       48 m_stringLength
6deb17c8  4000098        c          System.Char  1 instance       46 m_firstChar
6deb0ae8  4000099       10        System.String  0   shared   static Empty
    >> Domain:Value  03b32dc0:04641198 <<
6deb1718  400009a       14        System.Char[]  0   shared   static WhitespaceChars
    >> Domain:Value  03b32dc0:046417a8 <<

 

This error message gave me a hint that it was an issue related to probably a corrupted font on the customer’s machine. Hence I went directly into the "C:\WINDOWS\Fonts" folder and started looking for the Verdana fonts. I could notice that there were 3 types of fonts for Verdana.

clip_image003

I compared the same location on my virtual Windows 2003 OS and found the following fonts for Verdana:

clip_image004

BINGO!! The Missing font was Verdana ( True Type) . I copied this font from my machine and pasted into the fonts folder onto customer’s faulty server machine. The next few clicks of my mouse tried to launch BIDS 2008 again and created a New SQL Server Integration Service Project. The SSIS designer was now loaded successfully.

The only question that still remained unanswered was: How did the particular Verdana font go missing on Customer’s machine? What would have caused such a mischief?

Well J I’ll leave it you to think about it, until next time.

 

 

Author : Ajay(MSFT), SQL Developer Engineer, Microsoft 

Reviewed by : SMAT(MSFT), SQL Escalation Services, Microsoft