LabVIEW
incorporating Microcontroller debugger in Labview
I think you want to say that you try to interface to the Microchip DLL using the Call Library Node. If that causes LabVIEW to crash you know that you do something wrong. The immediate suspect would be the calling convention here, but since you say it "worked" in LabVIEW 8.6 this seems not the problem.
So then there are the other suspects:
1) Making sure that you do configure the Call Library Node parameter types to really match the actual DLL function parameters.
2) Most Call Library Node users favorite problem: Make sure that you allocate any buffere large enough for that function.
To point 2) above: Unlike LabVIEW VI's where you can pass in an empty array to let the VI resize it to the size required to fill in information and return it to the caller, this does usually not work when calling C functions. The C function can normally not and will not resize that buffer but simply expect the caller to have provided a buffer large enough to write in whatever it feels to write in. This is a variant of the cause of the infamous buffer overrun exploits that get fixed in regular patch updates on all major OSes nowadays.
So when you pass array and string pointers to DLLs make sure they are sized large enough for the function in question. For input only buffers this is obviously not a problem but any array or string pointer that receives information from the function has to be checked for that. To allocate a large enough buffer in LabVIEW you can either use the Initialize Array primitive or if you use LabVIEW 8.5 or later configure the Minimum Size value in the parameter configuration for such parameters
To short buffers can often not show any bad symptoms right away. It may seem to work either because the DLL function only returns small amounts of information that fit in the allocated buffer or it is overwriting illegal memory anyhow but that has not to be fatal immediately but only after you try to quit the application (LabVIEW goes and wants to properly deallocate everything and stumbles over destroyed pointers) or sometimes not at all (but it is still doing something illegal and with the potential to create a real mess after some time).
Seemingly small changes to the VI, or LabVIEW version changes, or compilation into an executable suddenly can cause the app to crash anyways since now the memory layout of your app has changed and the to small buffer suddenly lays right ahead of an important pointer in the memory so when the function overwrites that pointer illegally it causes a crash almost right away.
Well the Import Library Wizard does create VIs that use the Call Library Node. So you would be using that if the import library wizard would finish. Most likely your header file contains some definitions over which the import library wizard stumbles somehow. As such that is a bug/problem in the import library wizard and you have to work with NI support to let them know about it. They will need the header file that causes the problem.
As a workaround: Since it seems to work with earlier versions of LabVIEW you can simply import the header file in that version and let it create your VI library and then use that VI library in your 2009 version of LabVIEW.
