Exactly! The cmd line can only handle numbers 2^31. He is basically trying to create a number larger than the the maximum integer the cmd line can handle. If he would remove the /A like both of us have already told him he wouldn't have this problem.I haven't tried it on Vista, but on Windows 7 attempting to use set /a with a more-than-32 bit number gives an error with a helpful message.

Code: [Select]@echo off
:loop
set rand1=%random%
set rand2=%random%
set num2=
echo attempting to form long number from %rand1% and %rand2%:
set /a num2=%rand1%%rand2%
echo number: %num2%
goto loop

XP

Code: [Select]attempting to form long number from 21161 and 24341:
number: 2116124341
attempting to form long number from 52 and 9566:
number: 529566
attempting to form long number from 18750 and 23734:
number: 1875023734
attempting to form long number from 14704 and 24719:
number: 1470424719
attempting to form long number from 27451 and 25423:
number: -1549841873
attempting to form long number from 5098 and 27609:
number: 509827609
attempting to form long number from 16820 and 7515:
number: 168207515

Windows 7

Code: [Select]attempting to form long number from 5176 and 20064:
number: 517620064
attempting to form long number from 8211 and 24487:
number: 821124487
attempting to form long number from 9043 and 12230:
number: 904312230
attempting to form long number from 10230 and 15103:
number: 1023015103
attempting to form long number from 21127 and 4025:
number: 211274025
attempting to form long number from 11185 and 78:
number: 1118578
attempting to form long number from 24413 and 26665:
Invalid number. Numbers are limited to 32-bits of precision.
number:
attempting to form long number from 6451 and 30459:
number: 645130459
attempting to form long number from 10874 and 13098:
number: 1087413098
Another point for intrepid batch warriors to take note of is that set /a interprets anything starting with a zero as an OCTAL number and tries to evaluate it. Octal numbers can only have the digits 0 to 7. Trying to use 8 or 9 will cause an error. I see that the OP is first concocting a number from %random%%random%, and then in a loop trying out a succession of new numbers created the same way. Using two calls to random is going to generate a string which could be anything from 00 to 3276732767. Feeding this to set /a is all very WELL in XP as long as the first value is not 0 and the second value does not contain any 8s or 9s. In XP an overflow just results in a negative number and if the second random pair is the same as the first then the comparison test will be satisfied. In Windows 7 and maybe Vista overflow causes an error message and the compound number is not evaluated by set /a. However in BOTH XP and Windows 7 an attempt to create an invalid octal number causes an error message. I SUSPECT the OP has not run his "code cracker" script in XP long enough for the invalid-octal message to appear, as it surely would eventually. Or maybe some have scrolled by while his attention was elsewhere. In Win 7 and Xp with in either of these situations, the script will merrily proceed.

As has now been REPEATEDLY said, keep the generated values as STRINGS. I see that the OP uses the word "passcode" in a REMark. Passcodes are not "numbers" (quantities). They are strings of symbols which could just as validly be letters of the alphabet or punctuation or symbols like asterisks and hashes, as well as digits. So drop the /a switch from set.

Both XP and Windows 7:

Code: [Select]c:\>set /a num=01
1
c:\>set /a num=02
2
c:\>set /a num=03
3
c:\>set /a num=04
4
c:\>set /a num=05
5
c:\>set /a num=06
6
c:\>set /a num=07
7
c:\>set /a num=010
8
c:\>set /a num=011
9
c:\>set /a num=01234567
342391
c:\>set /a num=01234568
Invalid number. Numeric constants are either decimal (17),
hexadecimal (0x11), or octal (021).Sorry, I accidentally quoted myself (removed)
Here is a way to get a random key of a set length

Code: [Select]setlocal enabledelayedexpansion
set NumberOfDigits=4

set num1=
FOR /L %%N in (1,1,%NumberOfDigits%) do set /a randigit=!random! %% 10 & set num1=!num1!!randigit!
echo num1=%num1%
Adapting the OP's code slightly

Code: [Select]@echo off
setlocal enabledelayedexpansion
set NumberOfDigits=4

set num1=
FOR /L %%N in (1,1,%NumberOfDigits%) do set /a randigit=!random! %% 10 & set num1=!num1!!randigit!
echo num1=%num1%

mode 100,25
set /a num3=0

set time1=%time%

:rand1
color 0A
set num2=
for /l %%N in (1,1,%NumberOfDigits%) do set /a randigit=!random! %% 10 & set num2=!num2!!randigit!
set /a num3=%num3% + 1
title Searching for codebot... Number is %num1%
echo Scanning codebot %num2% %time%
REM ping localhost -n 2 > nul
if %num2%==%num1% goto rand2
goto rand1

:rand2
set time2=%time%
cls
echo.
title Passcode Found
echo Found in %num3% tries
echo Passcode: %num2%
echo Started at %time1%
echo Found code %time2%
echo.
echo Press any key to exit...
pause > nul

(These 2 screencaps were from DIFFERENT runs, which is why the code is different in each one.)

With the method I have shown, you can have seriously long code keys, by changing NumberOfDigits but of course the longer the key the more time it will take on average to find a match. You can see that with 4 digits the example run took a bit more than 26 seconds (without the ping delay). Each loop took around 10 milliseconds. I guess the ping delay is so you can actually see the numbers as they scroll. As the delay is about 1 second this would have taken around 40 minutes. You can imagine that with a longer key you would get longer processing times (and the increase would not be linear). With numbers (valid ones!) using the %random%%random% method I think the possible time would have been measured in days or weeks.