reg.present claims change even though there is none

[flassman]

Description of Issue

Running a reg.present state will always say something has changed even though it has not.
This makes highstate monitoring impossible.
The state is repeatedly executed which should not be the case.
This only happens if the vdata is passed as a string (see below)

Setup

HKEY_LOCAL_MACHINE:
  reg.present:
    - vname: MyTest
    - vtype: REG_DWORD
    - vdata: '00000001'

Steps to Reproduce Issue

use the state above and execute it twice. it claims something has changed even if nothing has changed during the second run:

      ID: HKEY_LOCAL_MACHINE
Function: reg.present
  Result: True
 Comment: Added HKEY_LOCAL_MACHINE to HKEY_LOCAL_MACHINE\
 Started: 12:08:47.424619
Duration: 8.998 ms
 Changes:   
          ----------
          inheritance:
              True
          reg:
              ----------
              Added:
                  ----------
                  Entry:
                      MyTest
                  Inheritance:
                      True
                  Key:
                      HKEY_LOCAL_MACHINE\
                  Owner:
                      None
                  Perms:
                      ----------
                      Deny:
                          None
                      Grant:
                          None
                  Value:
                      1

Versions Report

the problem was observed both with 2018.3.4 and 2019.2.2. Anyway, here comes the versions report:

Salt Version:
Salt: 2019.2.2

Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: 1.5
docker-py: Not Installed
gitdb: 2.0.3
gitpython: 2.1.8
ioflo: Not Installed
Jinja2: 2.7.2
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: 0.31.0
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.5.6
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 2.7.5 (default, Jun 11 2019, 14:33:56)
python-gnupg: Not Installed
PyYAML: 3.11
PyZMQ: 15.3.0
RAET: Not Installed
smmap: 2.0.3
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.4

System Versions:
dist: redhat 7.7 Maipo
locale: UTF-8
machine: x86_64
release: 3.10.0-1062.4.1.el7.x86_64
system: Linux
version: Red Hat Enterprise Linux Server 7.7 Maipo

and here the minion:

Salt Version:
Salt: 2019.2.2

Dependency Versions:
cffi: 1.12.2
cherrypy: 17.4.1
dateutil: 2.8.0
docker-py: Not Installed
gitdb: 2.0.6
gitpython: Not Installed
ioflo: Not Installed
Jinja2: 2.10.1
libgit2: Not Installed
libnacl: 1.6.1
M2Crypto: Not Installed
Mako: 1.0.7
msgpack-pure: Not Installed
msgpack-python: 0.5.6
mysql-python: Not Installed
pycparser: 2.19
pycrypto: Not Installed
pycryptodome: 3.8.1
pygit2: Not Installed
Python: 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)]
python-gnupg: 0.4.4
PyYAML: 3.13
PyZMQ: 18.0.1
RAET: Not Installed
smmap: 2.0.5
timelib: 0.2.4
Tornado: 4.5.3
ZMQ: 4.3.1

System Versions:
dist:
locale: cp1252
machine: AMD64
release: 2016Server
system: Windows
version: 2016Server 10.0.14393 SP0 Multiprocessor Free

[Ch3LL]

looks like im able to replicate this. we will need to get this fixed up

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[sagetherage]

not stale

[stale]

Thank you for updating this issue. It is no longer marked as stale.

[twangboy]

The cast_vdata function makes sure the data types match the expected type.
https://github.com/saltstack/salt/blob/master/salt/utils/win_reg.py#L751

[twangboy]

This is a bug fixed in the above PR ^^^^