Hell yeah Solomon, that helped indeed!!

And as we say in Holland; "you do your name proud", i'm definitely going to try to manually load System.Management.dll into the assembly, because that one that contains all the mountpoint info i need. The unsafe status is not an issue here, because the DB it's being used in is my own SqlManagement DB, so i'm the only user of it.

As for the suggestion of 'single treadedness', i can confirm that. If i run 2 console apps at the same time they both take much longer to complete.

When i cut down all my console apps / processes accessing Win32_Volume to just ONE at a time, i got much better runtimes.

That being said, i still have at random interval much longer runtimes. Which is probably my (single) console app or process interfering with SCOM which is probable also trying to use the same system.management.dll.

Knowing this, i'm rebuilding my stored proc that is called by all sorts of code in my management tool on demand, to a process that runs once a minute that updates a table using Win32_Volume that all other processes can access at will, thus cutting down the chances of hitting a busy Win32_Volume thread 🙂

And if for some reason the System.Management.dll in my CLR project does not work, your other suggestion of just calling the 6 KB console app from xp_cmdshell, is the next best thing. I think padded columns is the easiest: just a 7 substrings per returned row.

Somthing like this:

Select

cast(substring(outputstring, 1,25) as bigint) as var1,

cast(substring(outputstring,26,25) as bigint) as var2,

..etc..

from xpCmdShellOutput

Once i've tested all of the above options and the chosen one it is stable on my most challenging prod environment (3 way stretched cluster with 7 instances per node with 139 mountpoints) i will post my source code here for anyone else struggeling with this scale / stability problem.

Thanks again Solomon, and if we ever do meet in the flesh, i will most definitely buy you a drink 😀