No announcement yet.

Divid Error?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Divid Error?


    Program preformed illegal operation and will be shut down.

    In windows 98, get error on title bar "Epirpe20". Says it caused a "Divide Error" in module EPIHTB3N.DLL at 017f:028b340b. Could this be a printer .dll? I had same problem yesterday and changed
    some long integers to single percision and it seemed to work ok, until

    Hope someone knows how to fix this problem.



  • #2
    Originally posted by BRENT GARDNER View Post
    Could this be a printer .dll?
    Yes, I think it's part of Epson drivers.

    -- The universe tends toward maximum irony. Don't push it.

    File Extension Seeker - Metasearch engine for file extensions / file types
    Online TrID file identifier | TrIDLib - Identify thousands of file formats


    • #3
      That error is a divide by zero error, and while it can be caused by forces beyond your control (e.g. bad driver dll), it could also be caused by memory corruption due to a programming error somewhere prior to the call.

      I'd check my own code for valid parameters being passed to whatever the external driver is before I'd go complaining to the driver publisher.

      I had same problem yesterday and changed some long integers to single percision and it seemed to work ok..
      .. tells me that 'bad parameters' (programming error) is a genuine possibility.
      Michael Mattias
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]


      • #4
        Yes, It is a Epson printer Dll. Downloaded lastest driver which was 1998 and still have get error. So guess it's time for new printer. From
        trial and error, discovered that :

        Epson stylus color 740, gives error "divide error" if picture width/height is < 60%.

        The picture I am using will look distorted if I resize to 60% rule. So, I
        guess I'll have to tell users that they will have to get new printer or latest
        drivers or size picture width/height = 60 %


        • #5
          If you know the DLL name, you can get the version number from it, and compare against what you need to run at < 60%.

          i.e, your software can notify the user if his driver does not support his request BEFORE something bad (GPF) happens.

          And ony because I am in a really good mood today...
          ' get version of of any file
          FUNCTION FileVersionString(szFile AS ASCIIZ) AS STRING
            LOCAL major AS LONG, Minor AS LONG, Build AS LONG, SubBuild AS LONG
            LOCAL ResSize AS LONG
            LOCAL  ret AS LONG
            LOCAL Buffer AS STRING, DLLDate AS STRING
            Major=0: Minor = 0:  Build = 0
            ResSize = GetFileVersionInfoSize (szFile, ret)
            IF ResSize= 0 THEN
              FUNCTION = "No Version Info"
              EXIT FUNCTION
            END IF
            Buffer = SPACE$(ResSize)
            Ret =  GetFileVersionInfo(szFile, %NULL, ResSize, BYVAL STRPTR(Buffer))
          ' ** Read the VS_FIXEDFILEINFO info
            VerQueryValue BYVAL STRPTR(Buffer), "\", ffi, SIZEOF(@ffi)
            Major        = @ffi.dwProductVersionMs  \ &h10000
            Minor        = @ffi.dwProductVersionMs MOD &h10000
            Build        = @ffi.dwProductVersionLS MOD &h10000  ' this is for MY software which uses VERSION_MAJOR, VERSION_MINOR, 0, VERSION_BUILD under FILEVERSION
          '  SubBuild     = @ffi.dwProductVersionLS \  &h10000
            ' combine
            FUNCTION = STR$(Major) & "." & TRIM$(STR$(Minor)) & "." & LTRIM$(STR$(Build))   ' & "." & LTRIM$(STR$(SubBuild))
          END FUNCTION
          Note: I do not use "build" and "sub-build" the way Windows does (I reverse them), so you'll have to modify this if your driver publisher (as he probably does) uses "standard" versioning.

          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]