ERROR_DATATYPE_MISMATCH 0X0000065D: Wrong data type fix

You're running a script or a legacy app, maybe a PowerShell automation or an old VBA macro in Excel 2016, and bam—error 0x0000065D pops up. The exact text says "Data supplied is of wrong type." I've seen this most often when someone passes a string like "123" to a function that expects an integer, or when a registry API call gets a DWORD value where a string was expected. The trigger is almost always a mismatch between what a function expects and what you give it.

What's actually happening?

Windows has strict type checking in its API calls. Under the hood, functions like RegSetValueEx or WriteProcessMemory expect specific data types—integers, strings, binary blobs. If you feed a string where it expects a 32-bit integer, the system throws 0x0000065D. It's not a bug in Windows. It's a bug in your code or the data you're passing. The real fix is to trace back to the source of that data and either convert it or correct the call.

Fix step-by-step

1. Pinpoint the exact line or function call that fails. If you're in PowerShell, run $Error[0] | fl * -Force to see the full error record. In VBA, use Err.Number and Err.Description. Write down the function name. For example, RegSetValueEx in a registry script.
2. Check the data type expected by that function. Open the Microsoft documentation for that function. For registry calls, the dwType parameter tells you—REG_DWORD for 32-bit numbers, REG_SZ for strings. For other APIs, look at the parameter list on MSDN. I always keep a browser tab open to learn.microsoft.com for this.
3. Examine the data you're passing. In PowerShell, output the variable with GetType(). For example: $myVar.GetType().FullName. If it shows System.String but the function expects System.Int32, that's your mismatch. In VBA, use TypeName(myVar).
4. Convert the data to the correct type.
   • PowerShell: Convert a string to integer with [int]$myVar. Convert to double with [double]$myVar. For booleans, use [bool]::Parse($myVar).
   • VBA: Use CInt() for integer, CLng() for long, CDbl() for double. For registry, use CBool() if REG_DWORD holds a boolean.
   • C/C++: Use atoi() for string to int, strtol() for more control.
5. Test the corrected call. Run the script or macro again. If the error disappears, you're done. If it persists, move to the next step.
6. Check for hidden characters or nulls. Sometimes a string looks like "123" but has a trailing newline or null byte. In PowerShell, output $myVar.Length and compare to expected. Strip whitespace with $myVar.Trim(). In VBA, use Trim(myVar).
7. Review the calling code for type mismatches in structures. For example, if you're passing a SYSTEMTIME structure but filled it with strings instead of integers, you'll get this error. Check every field's type against the structure definition.

If it still fails

Here's what I've seen trip people up after the basics are covered:

• 64-bit vs 32-bit data sizes. On a 64-bit system, some API functions expect a DWORD (32-bit) but you might be passing a LONG (32-bit signed) and the function wants unsigned. Use [UInt32] in PowerShell or DWORD in C++.
• Registry redirection. If you're running a 32-bit script on a 64-bit Windows 10, the registry path might be virtualized under Wow6432Node. The data type returned there might differ. Always use RegOpenKeyEx with KEY_WOW64_64KEY flag to access the real 64-bit registry.
• COM object methods. If the error comes from a COM component like Scripting.FileSystemObject, the method might expect a Variant or a specific subtype. Use VarType() in VBA to check what the COM object sees.
• Log the exact hex value. If you still see 0x0000065D, capture the full error with Get-Error in PowerShell 7 or Format-List in older versions. Post the full output to a forum—sometimes the error code alone isn't enough.

The bottom line: this error is almost always your code, not Windows. Take a breath, check the data types at the boundary where the API call happens, and convert explicitly. You'll have it fixed in minutes.