VBA Debug Print producing unexpected and seemingly random output

Question

Can anyone shed some light on this. In MS Word VBA I have a trivial Sub that produces rather unexpected results. [Edit: this issue has been reproduced on several different installations of MS Word but so far only Win10]

Repro Environments:

Win10, Word 2010 (32-bit) PC
Win10, Word 2010 (32-bit) VM-Azure
Win10, Word 2016 (32-bit) PC
Win10, Word 2010 (64-bit) VM-Azure
Win10, Word 2016 365 @VincentG
Win10, Word 2007 (32 bit) @Ambie
Win10(64), Word XP @ThunderFrame
Win10(64), Excel XP @ThunderFrame
Win8.1(64), Word 2013 @miroxlav (first repro outside of Win10)
Win8.1(64), Office 2016 (32) @GSerg
Win10(64), Word 2007 (x86) @PartricK
Win10(64), Excel 2007 (x86) @PartricK

But no repro in:

Win7 (64), Word 2007 (32-bit) VM Azure
Win7 (64), Word 2010 (32?) @JohnColeman
Win7 (64), Word 2007 (32) @Slai
Win7 (64), Word 2003 (32) @GSerg
WinXP (32), Word 2010 (32) @GSerg
Win7 (64), Office 2010 (32)

Steps to reproduce: Open new Word document Open IDE (Alt + F11) Enter this code

Option Explicit

Sub test()
Dim i As Integer
For i = 1 To 100
Debug.Print vbCr
Next
End Sub

Run the test Sub.

My output varies each time the loop is run:

]Œ[p^"î;{Ñ[

]Œ[p^"î;{Ñ[

\ÒZžUÖè;qÑZ

or

ÿÿ

þþ@øø”¶(3

ÿÿ

or

>O

>O

>O

or

p

G   P‚j Ž¶&3@

p

Originally I thought I could recognize some content from my document, but now I get similar results for a blank document with nothing else open in Word.

It was quite disconcerting until I reproduced in the other Word installations, now its more of a distraction & puzzlement.

Any ideas about what's going on?

BTW: Effect seems to become more pronounced the more times the loop is run, although that might just be my imagination. — SlowLearner, Feb 01 '17 at 03:27
Interesting. I can't replicate (with Word 2010 on 64-bit Windows 7). — John Coleman, Feb 01 '17 at 03:50
@JohnColeman I'm jealous what's your environment? (wow that was quick) — SlowLearner, Feb 01 '17 at 03:51
I was in the process of adding the environment when you asked about it. I'm the one that is jealous. My IDE seems boring in comparison :) — John Coleman, Feb 01 '17 at 03:53
@JohnColeman I have just tried in Win 7 (64), Word 7 (32) and can report the result was satisfyingly boring... seems like a Windows issue? — SlowLearner, Feb 01 '17 at 04:02
Sounds like a Windows issue. If I had to guess, it probably has something to do with Window's move towards a Unicode world. Exactly how, I have absolutely no idea. — John Coleman, Feb 01 '17 at 04:06
@Mat'sMug - mate... first thing I did was disable RD! But, it has been repo'd on 3 different machines.... Happy to say RD was innocent :-D — SlowLearner, Feb 01 '17 at 04:06
any common add-in? seems like they might share some common corrupted component. You can also try `Debug.Print VBA.vbCr` just in case — Slai, Feb 01 '17 at 04:09
@Slai Thanks for your interest. No. No common addins; in fact for the most part the VMs are basically clean machines that I use for testing. As per comment above I disabled RD (RubberDuck for VBA) and a few other VBA IDE addins but that was on my main PC. I also rebooted and problem persisted. — SlowLearner, Feb 01 '17 at 04:14
@Slai Good idea, tried VBA.vbCr and got the same result - but this time on a new VM: Win10, Word10 (64-bit) — SlowLearner, Feb 01 '17 at 04:26
Tried on Office 2016 365, Windows 10, got some `8(äBwAjc` as a result. — Vincent G, Feb 01 '17 at 07:58
Tried `Debug.Print Chr(13)` with the same result, but `Debug.Print Chr$(13)`is working fine? — Vincent G, Feb 01 '17 at 08:01
@VincentG - nice suggestion. I just tried Chr$(13) and I still get the junk... :-/ — SlowLearner, Feb 01 '17 at 10:40
I'm Windows 10 Word 2007 (32 bit) and I get `eeeeee ¥üVe.` amongst a whole load of other junk. Seeing as `Debug.Print vbCrLF` works fine, I'd be interested to know what happens on a genuine Mac OS.. — Ambie, Feb 01 '17 at 13:39
can't reproduce on Win 7 (64), Word 2007 (32), so I blame it on the VBA 7. I even tried changing to different mono-space fonts. — Slai, Feb 01 '17 at 15:23
@Ambie - thanks for sharing :-) I've a mate with Mac OS so might hit him up for a test... — SlowLearner, Feb 01 '17 at 20:52
@Slai - I *think* a pattern is emerging... and Win10 is strongly implicated! — SlowLearner, Feb 01 '17 at 20:53
No-repro: Win7 (64), Word 2003 (32); Win 8.1 (64), Word 2016 (32); WinXP (32), Word 2010 (32). — GSerg, Feb 01 '17 at 20:58
Win 10 (64), Word XP is a repro but different characters, and different characters *each* time. Win 10 (64) Excel XP is a repro, but all lines show *only* `½s`, or *only* `½s` and `V`, or sometimes no repro. — ThunderFrame, Feb 01 '17 at 21:24
@ThunderFrame I'm getting different characters each time I run this, I'll make this more clear... thanks for confirming. Really looks like a Win10 thing — SlowLearner, Feb 01 '17 at 21:27
Interesting, if I use `Debug.Print vbCr;` there is no repro. If I use `Debug.Print vbCr; vbCr`, then *many* but not *all* outputs are `v` or `Cr`, which suggests a size, offset or null-terminator is out of whack. — ThunderFrame, Feb 01 '17 at 21:40
@ThunderFrame I just tried `debug.print vbcr;` and got this: `$à.ª$†¶3@ˆ` but the output was MUCH cleaner than before... only a little bit of junk — SlowLearner, Feb 01 '17 at 21:43
@GSerg - Repro: Win8.1 (64) Word 2013. Output garbage randomly varies if run multiple times. — miroxlav, Feb 01 '17 at 21:57
With a Win10x64 (En) + Office 2007 (x86), both Word and Excel do reproduce similar symptom, however not all lines are gibberish, and sometimes it prints a few characters of my code. But if `Debug.Print i & vbCr`, it's clean! Temporary solution is to use `vbLf` or `vbCrLf` instead, they don't reproduce this symptom. — PatricK, Feb 01 '17 at 22:20
@GSerg - I'm unsure which is more desperate: using Office 2010 in Windows XP, or Office XP in Windows 10. ;-) — ThunderFrame, Feb 01 '17 at 22:25
I stand corrected. Repro on Win 8.1 (64), Office 2016 (32). It just happened so that it looked normal when I tried it a couple of times. Tried five times in a row and it happened. And then it started happening easier (happens straight away after restarting Word/Excel). — GSerg, Feb 02 '17 at 12:58
@GSerg awww man you had me all excited... how sad is that? will amend [oh you did, thanks :-)] — SlowLearner, Feb 02 '17 at 13:04

score 2 · Accepted Answer · answered Feb 01 '17 at 21:36

Not an answer, but here's a p-code dump of the word doc in .doc format:

Looks like the vbCr isn't corrupted

_VBA_PROJECT parsing done.
-------------------------------------------------------------------------------
Module streams:
Macros/VBA/ThisDocument - 932 bytes
Macros/VBA/Module1 - 1478 bytes
Line #0:
        Option  (Explicit)
Line #1:
Line #2:
        FuncDefn (Sub test())
Line #3:
        Dim
        VarDefn i (As Integer)
Line #4:
        StartForVariable
        Ld i
        EndForVariable
        LitDI2 0x0001
        LitDI2 0x0064
        For
Line #5:
        Debug
        PrintObj
        Ld vbCr
        PrintItemNL
Line #6:
        StartForVariable
        Next
Line #7:
        EndSub

I know this 'not an answer' but it is the answer that showed me the most new stuff - thanks. — SlowLearner, Mar 09 '17 at 10:37

score 2 · Answer 2 · edited May 23 '17 at 11:53

2

@Comintern and I have long speculated that the Immediate Window is in fact a pipe, or a conduit for stdIn/stdOut.

If we work on that basis, then this answer has some insights:

https://stackoverflow.com/a/25843879/5757159

A text stream is an ordered sequence of characters composed into lines, each line consisting of zero or more characters plus a terminating new-line character.

Characters may have to be added, altered, or deleted on input and output to conform to differing conventions for representing text in the host environment.

So it seems that Windows 10, might be getting something wrong when it processes the streams?

The workaround is to ensure that Debug.Print statements never end in vbCr, Chr(10) or Chr$(10)

edited May 23 '17 at 11:53

Community

1
1

answered Feb 01 '17 at 22:37

ThunderFrame

9,352
2
29
60

I'll take a look, did a few more tests: `Debug.Print vbCr & " "` is clean `Debug.Print vbCr & Chr$(10)` is clean `Debug.Print Chr$(10)` is clean `Debug.Print vbCr & ""` is dirty `Debug.Print vbCr & vbNullString` is dirty `Debug.Print Chr(13)` is dirty – SlowLearner Feb 01 '17 at 22:45
`Debug.Print vbCr & Chr(0)` appears to be clean. – ThunderFrame Feb 01 '17 at 23:05
`Debug.Print Chr(0) & vbCr` clean `Debug.Print Chr(0)` clean – SlowLearner Feb 01 '17 at 23:42

score 0 · Answer 3 · answered Apr 02 '18 at 19:10

0

I have a similar issue: Debug.Print vbCr prints either a blank line and nothing, or a blank line and "lls". It happens randomly, I tried the same fonction with same parameters many times, and each time the printed result is different (either one of the above).

I found an alternative:

Debug.Print ""
Debug.Print "My text"

This alternative spoils one line of code, but the result is indeed one blank line and "My Text", without any extra random text.

answered Apr 02 '18 at 19:10

Jérémy

1

Hi there, welcome to SO :-) Yes, `Debug.Print "" ` is a workaround but more to the point WHY does the `Debug.Print` statements that include `vbCr` fail? Anyway - I hope this helped you preserve your sanity :-) – SlowLearner Apr 03 '18 at 02:25

VBA Debug Print producing unexpected and seemingly random output

3 Answers3