Yeah, they're different. Granted, both involve kernel data corruption of some nature, but the actual type of data and the check used to inspect the integrity are different, with the 0x139 being newer checks implemented.
If anyone can correct me if I'm wrong, but I believe the newer checks stem from an attempt to prevent an application from trying to gain unauthorized kernel access and therefore run amok, using security checks on common procedures that attempt this (be they intended and therefore malicious, or unexpected). Malware particularly likes to use exception handling methods of Windows as a gateway into the kernel, and this security check stops that in its tracks often so that instead of the malicious code taking control during an exception as it normally would take place, the kernel just stops it all in its tracks and forces a bugcheck, with no permission to perform exception handling on it. This leaves the kernel being more paranoid and giving less chance for recovery on such faults, but personally from what I see reading what it checks for I don't believe there's any instance where a recovery can occur from such events, so it would be moot (and dangerous) to give a vain opportunity that would just lead to more security holes.
Think of a spy movie where the spy needs to get a device into like the security room of a high security environment but he can't just walk in and take it there. Instead he intentionally gets caught by the authorities, they frisk him and carry the seemingly innocent device to the room, where it'll do its work there. Wasn't there a Mission Impossible movie that did something like this? Anyways, something like that. These new security checks would be akin to having the authorities not take the device but instead destroy it right there on site and lock down everything to prevent further compromise.
