We have all done it, get some sort of cryptic error and the first place we go to search is Google hoping the sea of message boards and blog posts will save the day. Many times this has been a saving grace and we find the solution and others it sends us down a rabbit hole with no results. Last night my team experienced this exact case so let me tell you what happened.
It all started with an error
As we started our Disaster Recovery testing someone executed one of the SSIS packages and got the following error.
Could not load package “xxxxxxxxxx.dtsx” because of error 0x80131534.
Description: The package failed to load due to error 0x80131534 “(null)”. This occurs when CPackage::LoadFromXML fails.
Source: {9934C764-F98C-49E4-85E6-7062B6589435}
Now go ahead and google this error six ways from Sunday and you will get all types of information regarding the wrong version of dtexec, failed upgrade of a project in VSTS and issues with .net versions and script tasks. This sent my team off and running looking into all those areas and calling other teams to start looking into server configuration issues and asking development teams if they had a bad upgrade.
Let me pause here for a second because while google searches can be great, it’s also in so many cases caused us to forget basic troubleshooting skills, we all too often take google as gospel and forget to do anything on our own. Why do I say this? Because that is exactly what happened here. When this issue was escalated to myself, I took a step back and looked to see if all packages were failing or just some. The answer, in this case, was just some were. Troubleshooting 101, when you have partial errors like this take a look into what is different, in this case, there was one difference between how the successful packages versus the failed packages where running and that was the windows user was different. So, I changed the user and ran the package and bye-bye error.
Turns out that outside of all the wonderful google advice that is available, there are two other reasons why you may see this error.
- The account running dtexec may not have read permission to the SSIS package/.dtsx file
- The account running dtexec may not have execute permission on the dtexec.exe folder. YES, I said folder because if you just give it to the file then you’ll run into more problems with the underlying dependencies.
The moral of the story is, use your troubleshooting skills first before running off to google for the answer.